General Concept of Integration

FireBack comes as executable binary for MacOSX, Linux and Windows. You do not need to treat this software as a source code, or boilerplate. This is a system service, like any other .exe or .deb file that you can download and install, natively.

When FireBack starts as system service, it listens to port 4500 for incoming requests. It would handle a set of requests publicly which you can find in "All APIs in a glance" section.

You can use Postman or other HTTP(s) software to create an account, sign in, create workspaces and so on. This project meant to be used independently from rest of your backend code.

Your front end, desktop app or mobile app, can directly talk to Fireback without going through another microservice or proxy inside your codebase, if you do not need extra layers of code, for example when user signs up.

POST to http://localhost:4500/token with Header authorization will return some information about the token, if the user still logged in, roles, etc. You can add a decorator in the backend, for each request, it will check the Header Authorization against this endpoint, and get the information from there, if token expired, just reject the request and front-end will return the login page or other refresh token mechanism.

SQL Operations on the data

We would highly recommend to use the REST API or GRPC (if you are using FireBack+) communication for information you might need and do not access the database tables directly.

This is easily achievable. Anyways if you really need to do that, you can access the the tables and create joins or modify data in your backend.

The structure of tables in this project are studied for long, they are not subject to major changes over incoming versions.