Build flask project with Firebase
Flask-boiler helps you build fast-prototype of your backend.
You may structure your project in this way:
__init__ of your project source root:
import os from flask_boiler import context from flask_boiler import config Config = config.Config testing_config = Config(app_name="your_app_name", debug=True, testing=True, certificate_path=os.path.curdir + "/../your_project/config_jsons/your_certificate.json") CTX = context.Context CTX.read(testing_config)
Note that initializing
certificate_path is unstable and
may be changed later.
In your project code,
from flask_boiler import context CTX = context.Context # Retrieves firestore database instance CTX.db # Retrieves firebase app instance CTX.firebase_app
from flask_boiler.factory import ClsFactory from flask_boiler import schema, fields # Creates a schema for serializing and deserializing to firestore database class TestObjectSchema(schema.Schema): # Describes how obj.int_a is read from and stored to a document in firestore int_a = fields.Raw( load_from="intA", # reads obj.int_a from firestore document field "intA" dump_to="intA" # stores the value of obj.int_a to firestore document field "intA" ) int_b = fields.Raw(load_from="intB", dump_to="intB") # Declares the object TestObject = ClsFactory.create( name="TestObject", schema=TestObjectSchema, # Either MyDomainModelBase (specify cls._collection_id) # or SubclassOfViewModel # TODO: ADD MORE DOCS base=PrimaryObject ) # Creates an object with default values with reference: "TestObject/testObjId1" # (but not saved to database) obj = TestObject.create(doc_id="testObjId1") # Assigns value to the newly created object obj.int_a = 1 obj.int_b = 2 # Saves to firestore "TestObject/testObjId1" obj.save() # Gets the object from firestore "TestObject/testObjId1" retrieved_obj = TestObject.get(doc_id="testObjId1") # Access values of the object retrieved assert retrieved_obj.int_a == 1 assert retrieved_obj.int_b == 2 # Deletes the object from firestore "TestObject/testObjId1" retrieved_obj.delete()
There are 2+ ways to run the view layer.
Document-As-View: Persist all view models to firestore, and client reads/writes to firestore.
- Document is refreshed every time the bounding domain models change
- Firestore serves Document at near 0 latency (cached) if the client attaches a listener to the view model
- Performance depends on how often the domain model is changed
Flask-As-View: only the binding structure is persisted, and client reads/writes to flask REST API resources.
- Bounding domain models are read every time the client requests the resource
- May experience latency, but overall lower in server cost since the ViewModel is not persisted
- Performance depends on how often the view model is read
A combination of 1 and 2: build read-intensive microservices with Document-As-View and change-intensive microservices with Flask-As-View.
Flask-boiler is mostly for building a fast prototype of your backend. As you keep developing your product, we recommend that you switch to a relational database for your domain model layer if your data has many references, and WebSocket/REST API for view layer. This does not mean that flask-boiler is not runtime efficient, but that simplicity is always a compromise and firestore can be expensive.
Document-As-View has better performance if data is read more than it's changed, and the view models served are limited or specific to a user.
Flask-As-View has better performance when the domain model is changed often, and the client rarely reads all data available to a specific user.
Flask-boiler is not a well-tested concept, but criticisms are welcomed. At least, we can strive to build a backend framework that is simple and friendly to beginners who want to prototype their backend easily so that they can focus on transforming ideas.
Decoupled Domain Model and View Model
Using Firebase Firestore sometimes require duplicated fields across several documents in order to both query the data and display them properly in front end. Flask-boiler solves this problem by decoupling domain model and view model. View model are generated and refreshed automatically as domain model changes. This means that you will only have to write business logics on the domain model without worrying about how the data will be displayed. This also means that the View Models can be displayed directly in front end, while supporting real-time features of Firebase Firestore.
Rather than configuring the network and different certificate settings for your database and other cloud services. All you have to do is to enable related services on Google Cloud Console, and add your certificate. Flask-boiler configures all the services you need, and expose them as a singleton Context object across the project.
Since all View Models are persisted in Firebase Firestore. Even if your App Instance is offline, the users can still access a view of the data from Firebase Firestore. Every View is also a Flask View, so you can also access the data with auto-generated REST API, in case Firebase Firestore is not viable.
By separating business data from documents that are accessible to the front end, you have more control over which data is displayed depending on the user's role.
All ViewModels have automatically generated documentations (provided by Flasgger). This helps AGILE teams keep their documentations and actual code in sync.
When you need better performance or relational database
support, you can always refactor a specific layer by
adding modules such as
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
|Filename, size||File type||Python version||Upload date||Hashes|
|Filename, size flask_boiler-0.0.1a4.tar.gz (22.8 kB)||File type Source||Python version None||Upload date||Hashes View hashes|