User-flow built for you.
Fireback is an opinated backend framework, suitable for most commercial products (Gin, Laravel, Nest.js replacement) a http server with database connection, which comes with powerful code gen tools, and ready to use flows and plugins. Fireback can create production ready projects even in a business day, giving you fully know what do you need.
Fireback React is also a project related to fireback, which applies the same principles to build front-end (Web, Mobile and Desktop) with high quality, and fast.
Fireback Android/IOS are experimental native projects, which we gen a lot of code for them, but my main business income is from Cordova/Web and backend so that's the main focus.
You can use a fireback backend with any other frameworks (Xamarin, Angular, Vue.js ...) if you want. In the end it's a normal http server (POST, GET, etc) which supports open api 3 docs and also post man, but the code we generate is mainly for react.js, you can either code front manually or open a pull request for codegen support.
Fireback can be used as a plugin or a template, it's your choice. Also please note that fireback is a production project, means you might need few hours of learning it, unlike a simple hello world projects in Gin. (Fireback uses gin)
The fastest demo I have shown is around 7 minutes to build a new feature and deploy it.
You have following options to install fireback:
You can install fireback using go install github.com/torabian/fireback/cmd/fireback@latest
This would install it from source, and should be available in go/bin
folder.
Sometimes, your go/bin
folder is not in your path, you need to add it. (Also check the next section)
If your system is reporting that the fireback
command is missing, make sure you have followed the Go installation guide correctly. Normally, it means that the go/bin directory in your User's home directory is not in the PATH environment variable. You will also normally need to close and reopen any open command prompts so that changes to the environment made by the installer are reflected at the command prompt.
Check the github releases, I release it for major operating systems. For some OS, I also have created installer, so you can access it. Put the binary, and add it to your path, call it fireback
or fireback.exe
to make it easier in order to access it in Powershell, Mac or Linux terminal.
fireback new --name projectname --moduleName github.com/yourorg/yourproject
commandMakefile
. Check that so you can see which commands you can use..vscode
folder, You need to install https://marketplace.visualstudio.com/items?itemName=emeraldwalk.RunOnSave
extension, in order to make it easier for you to generate, and compile code.Tasks: Run Task
, and then you can use Generate new module
command to create new modulesImportant: You might need go mod tidy
in your project directory.
Important: Fireback projects do not have special build system. Makefile is all there, you can modify it the way you want. It's pure golang project, so stick to go build ...
or go run ...
commands.
You should be able to create your binary, and Makefile by default puts the created binary to your path. Modify the Makefiles based on your preference of using golang.
Project is only Golang app, you can run it how you might want, but also check the Makefile
and cmd/fireback/Makefile
, those are convinient
scripts to build (Only on mac at the time of writing this)
https://www.youtube.com/watch?v=G2Wjeq7ZmS0
Fireback is a backend/system software programming framework, which intends to generate backend in minutes instead of months, give an opinionated structure of software and deliver process, written in Golang and C++.
Fireback products using Module2 yaml language, as the foundation of the business logic, and products created by that will benefit from auto generated direct SDK for Android Java, SwiftUI, React.js, with a complete dto, actions, rpc exposure.
Fireback starts with zero configuration, will be always a compiled software, uses 5MB ram and weights less than 10MB for server, 30MB for desktop, and C++ version can be compiled for devices with less 1MB of on chip memory.
The reason I have started this project was to change the course of action for entire software development I am involved for next 30 years, they include but not limited to:
Fireback itself is a backend project, based on Golang, but there are few other projects inside clients
folder. The mindset behind it is, to build backend on Go, front-end on React, Mobile apps on Native Android and IOS. Fireback well supports other frameworks, such as react native, angular, ... but we are not going to give you boilerplates. Build backend on Fireback, and use it's restful api, or sdk generator, if available for your framework.
This is the backend, with few modules coming, such as user management, permissions, codegen based on Gin and Gorm. It's production ready, you get it by cloning this repository.
This is the front-end boilerplate (it's different from react codegen) gives you general screens of an app, signin, signup. It will be updated over time, but it's reliable enough to use it.
This is a set of components for building an Android app. It does not really depend on fireback backend, but it's a quick start to build project on Android. It's purely an Android Java project without any modification to details of Android structure. Few libraries are added, such as RxJava, ... Signup, Signin, ... and few screens and activities are there, and you can modify them.
Similar to fireback-android, this is also a boilerplate to build IOS apps using SWIFT and SWIFTUI. There is cocopod, and fireback generated sdk inside of it, Promise
library has been installed, and few onboarding screens, etc will be there.
You can clone those projects independently as your boilerplate without fireback also. Plus, you can create android or ios app with fireback, without these projects, it's just gonna move you forward faster by giving few screens. Also these are boilerplate, they are not "library". Once you clone them, any update to it, from us, will be manually, except the fireback gen android/ios which gives sdk from your backend.
Fireback also might over time add and improve support for react native, ionic, flutter, also there is a C++ and Java version fully written in backend. These projects are not intended to be fireback main focus, they are my personal tools for serving customers with these technologies.
Fireback is a general name, but refers to few products in itself. Fireback microservice is a way to authenticate other backend project, which could be written by any other languages, like node.js, php, etc. Fireback Module2 is a language, a declarative way of defining entities (both models, and business logic), Fireback Core, which is the framework source, that I internally use for client projects, and not all the toolset is exposed at all. Fireback for Android, is the android tools written in Java to connect to Fireback core products, the same goes for Fireback React, and Fireback Swift. React-Iron and React-Native-Iron are two boilerplates for react and react-native which are open-source, and kinda a way to start react(native?) projects but influenced by the Fireback anyways.
This is a language that we define our modules, even fireback workspace module (which everything depends on) is written using this language. Language itself is valid yaml, or even could be presented in json format.
Document can be created in modules/mymodule
folder, and by convention needs to end with Module3.yml
for VSCode auto compile.
Define path
and name
, which represents the folder name (and the generated folder as well) and name of the module.
Always, camelCaseVariables in entire of the definitions
path: mymodule
name: mymodule
Defining entities is super straight-forward, it a flat array in the module.yml file. Entity name Must be singular by definition.
path: mymodule
name: mymodule
entities:
- name: customer
fields:
- name: firstName
type: string
- name: age
type: int64
As visible, each entity has few sections, the name
and fields
are the most important one. Each field, needs to at least
define name and it's type. Fireback types are all golang primitives int64
, string
, bool
... and few custom defined by fireback:
object
and array
typesEach field can be object or array, when defined as such, it can have children properties called fields
, similar to the original entity,
and this relation can be nested indefinitely.
For example, customers can be extended like this:
path: mymodule
name: mymodule
entities:
- name: customer
fields:
- name: firstName
type: string
- name: age
type: int64
- name: address
type: object
fields:
- name: postalCode
type: string
- name: streetAddress
type: string
- name: visitToOffices
type: array
fields:
- name: visitDate
type: datenano
- name: visitDurationInSeconds
type: int64
As we see, array and object field types have their own fields, there will be separate tables in the database for them, and they are linked to the parent table automatically using foreign key and unique id by any fireback product.
Note1: If the field type is array, its name must be plural Note2: object/array ARE DIFFERENT from one/many2many types
one
and many2many
types.While defining these types are similar to object/array types, there are significant differences.
Unlike array/object, fireback does not automatically create them. Instead, they are treated as completely separate features/business model, you just add them by giving their uniqueId.
For one
, there will be a string field added called (name+Id) and for the many2many, will be string array (name+ListId).
When updating the entity with such relation, you need to specify those keys rather than the object itself.
When querying, fireback will use the original fields to give you back your selection.
It's better to use many2many
and one
if applicable, to separate the structure of the code. From data base perspective, all 4 of those
fields are gonna have their own tables.
json
typeAlthough fireback emphasizes on data normalization, there is a json type supported, which will be JSON field in the database, or string if the target database does not support it. It is useful when the data structure is unknown, does not need strict validation (such as config for an specific widget). Never over use, if data might be queried later. [ In some databases, such as postgres, there is significant improvement on querying or store json fields, but using this field would limit fireback and unforeseeable database operation in future. ]
entities:
- name: customer
fields:
- name: config
type: json
matches:
- dto: CustomerConfigDto
If you specify a list of matches
entities or dto, fireback might use validation from them, and generated Swift/Ts/Java code for front-end
will be giving some helper functions to detect the actual type of the column there. If you have limited and known dto for that, it's good practise to mention them in matches section.