zrb 0.28.0__py3-none-any.whl → 1.0.0a10__py3-none-any.whl

zrb/builtin/project/add/fastapp/app/template/src/kebab-zrb-app-name/docs/README.md

@@ -1,3 +0,0 @@
-# Table of Content
-
-- [Modular Monolith](modular-monolith/README.md)

zrb/builtin/project/add/fastapp/app/template/src/kebab-zrb-app-name/docs/modular-monolith/README.md

@@ -1,120 +0,0 @@
-🔖 [Table of Contents](../README.md)
-
-# Modular Monolith
-
-PascalZrbAppName has several features that you can activate/deactivate using environment variables. It also has some communication patterns like API, RPC, or Event.
-
-![Modular monolith](images/fastapp.png)
-
-## Frontend, API, Event, and RPC
-
-First, you have Frontend and API.
-
-Frontend is intended to be accessed by users. It has buttons, links, and a nice user interface. This user interface usually needs to access API endpoints to translate user action into server requests.
-
-Aside from the Frontend, the API endpoints are also accessible by external systems. You might have third-party client apps, webhook, or even IOT devices.
-
-In PascalZrbAppName, most API requests will be translated into events/RPC calls. The difference between events and RPC calls is as follows:
-
-- Event
-    - Once an event is fired, event handlers will pick up the message.
-    - PascalZrbAppName will not wait for the process to be completed. It just fires the event, lets the event handler handles the message, and continues with other processes.
-    - You usually use events if you don't need an immediate response. For example:
-        - You train a machine learning model. The process can take hours or even days. You just want to trigger the training, and you don't need immediate results. Once the training has been completed, you can let the event handler send a notification email to the user.
-        - You deal with warehouse fulfillment progress. The fulfillment might take a very long time, you can't make sure that the user will get immediate feedback.
-- RPC (Remote procedure call)
-    - Once an RPC call is fired, RPC Server will pick up the message.
-    - PascalZrbAppName will wait for the RPC Server to return the result before continuing with other processes.
-    - You usually use RPC calls if you need an immediate response. For example:
-        - You want to fetch user data from the database. You can't give any HTTP Response before you get the result from the database
-        - You want to update a product description. You can only return HTTP Response to the user once the process is completed (or failed).
-
-## Feature flags
-
-The following are some feature flags to activate/deactivate the features:
-
-- Frontend:
-    - `ZRB_ENV_PREFIX_APP_ENABLE_FRONTEND=true`
-- API:
-    - `ZRB_ENV_PREFIX_APP_ENABLE_API=true`
-- RPC Caller/Event Publisher: This feature is always activated
-- Auth module:
-    - Auth API:
-        - `ZRB_ENV_PREFIX_APP_ENABLE_AUTH_MODULE=true`
-        - `ZRB_ENV_PREFIX_APP_ENABLE_API=true`
-    - Auth RPC Server:
-        - `ZRB_ENV_PREFIX_APP_ENABLE_AUTH_MODULE=true`
-        - `ZRB_ENV_PREFIX_APP_ENABLE_RPC_SERVER=true`
-    - Auth Event Handler:
-        - `ZRB_ENV_PREFIX_APP_ENABLE_AUTH_MODULE=true`
-        - `ZRB_ENV_PREFIX_APP_ENABLE_EVENT_HANDLER=true`
-- Log module:
-    - Log API:
-        - `ZRB_ENV_PREFIX_APP_ENABLE_LOG_MODULE=true`
-        - `ZRB_ENV_PREFIX_APP_ENABLE_API=true`
-    - Log RPC Server:
-        - `ZRB_ENV_PREFIX_APP_ENABLE_LOG_MODULE=true`
-        - `ZRB_ENV_PREFIX_APP_ENABLE_RPC_SERVER=true`
-    - Log Event Handler:
-        - `ZRB_ENV_PREFIX_APP_ENABLE_LOG_MODULE=true`
-        - `ZRB_ENV_PREFIX_APP_ENABLE_EVENT_HANDLER=true`
-
-By activating/deactivating the feature flags, you can control PascalZrbAppName's communication pattern. You can make it respond to all API requests, events, and RPC calls. Or you can make it respond to API requests but ignores RPC/Event calls.
-
-
-# PascalZrbAppName as a monolith
-
-PascalZrbAppName will behave like a monolith if you activate all the features.
-
-![Monolith](images/fastapp-monolith.png)
-
-A Monolith handles everything. Compared to microservices, a monolith is easier to maintain/deploy.
-
-If you only have a single developer team, a monolith is much preferable.
-
-However, since everything run in a single application, a problem in any component can affect the whole system. For example, if your Auth RPC Server takes up a lot of CPU usage, you might not be able to handle the event log.
-
-Scaling a monolith application might also be challenging. The easiest way to scale up a monolith application is by using a more resourceful (and expensive) server. This probably won't be a good idea if your application receives spike requests once in a while. You will have to pay for the highest capacity all the time.
-
-# PascalZrbAppName as a microservices
-
-You can spawn multiple PascalZrbAppName, each with different configurations. By doing so, you can have a distributed architecture where some of your applications are deployed on cheaper Virtual Machines (like [Spot Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html)).
-
-Furthermore, you can spawn more services if you encounter spiked requests. For example, there is a flash sale and you only need to spawn more services to handle sales orders. Once the flash sale ended, you can scale down your services.
-
-![Microservices](images/fastapp-microservices.png)
-
-Microservices are more difficult to deploy/maintain since you have multiple instances of your services.
-
-You will likely need different teams to handle each service.
-
-# Run PascalZrbAppName as a Monolith or Microservices
-
-By using [Zrb](https://pypi.org/project/zrb), you will be able to run PascalZrbAppName as either a Monolith or Microservices. You don't need to set the feature flags manually.
-
-```bash
-# Run PascalZrbAppName as a monolith
-zrb project kebab-zrb-app-name monolith start
-
-# Run PascalZrbAppName as a monolith inside a container
-zrb project kebab-zrb-app-name container monolith start
-
-# Run PascalZrbAppName as microservices
-zrb project kebab-zrb-app-name microservices start
-
-# Run PascalZrbAppName as microservices inside containers
-zrb project kebab-zrb-app-name container microservices start
-
-# Deploy PascalZrbAppName to Kubernetes as a monolith
-zrb project kebab-zrb-app-name monolith deploy
-
-# Deploy PascalZrbAppName to Kubernetes as a microservices
-zrb project kebab-zrb-app-name microservices deploy
-```
-
-Hopefully this will make your development/deployment process easier.
-
-You can run your application as a monolith in your local computer, and deploy it as microservices later.
-
-
-🔖 [Table of Contents](../README.md)

zrb/builtin/project/add/fastapp/app/template/src/kebab-zrb-app-name/loadtest/.gitignore

@@ -1,2 +0,0 @@
-__pycache__
-.venv

zrb/builtin/project/add/fastapp/app/template/src/kebab-zrb-app-name/loadtest/locustfile.py

@@ -1,28 +0,0 @@
-import os
-
-from locust import HttpUser, between, task
-
-access_token_cookie_key = os.getenv("APP_AUTH_ACCESS_TOKEN_COOKIE_KEY", "access_token")
-admin_username = os.getenv("APP_AUTH_ADMIN_USERNAME", "root")
-admin_password = os.getenv("APP_AUTH_ADMIN_PASSWORD", "toor")
-
-
-class QuickstartUser(HttpUser):
-    wait_time = between(1, 5)
-
-    @task(2)
-    def homepage(self):
-        self.client.get("/")
-
-    @task
-    def permissions(self):
-        self.client.get("/api/v1/auth/permissions")
-
-    def on_start(self):
-        login_response = self.client.post(
-            "/api/v1/auth/login",
-            json={"identity": admin_username, "password": admin_password},
-        )
-        login_response_json = login_response.json()
-        access_token = login_response_json.get("access_token")
-        self.client.cookies.set(access_token_cookie_key, access_token)

zrb/builtin/project/add/fastapp/app/template/src/kebab-zrb-app-name/loadtest/pyproject.toml

@@ -1,21 +0,0 @@
-[tool.poetry]
-name = "kebab-zrb-app-name-loadtest"
-version = "0.0.1"
-description = "Load test for zrbPackageName"
-authors = ["zrbAppAuthorName <zrbAppAuthorEmail>"]
-packages = [
-  {include = "kebab-zrb-app-name-loadtest", from = "../.."},
-]
-
-[tool.poetry.dependencies]
-python = ">=3.10.0,<4.0.0"
-locust = "==2.16.1"
-
-[tool.poetry.dev-dependencies]
-flake8 = "~6.0.0"
-black = "~24.3.0"
-isort = "~5.13.2"
-
-[build-system]
-requires = ["poetry-core>=1.0.0"]
-build-backend = "poetry.core.masonry.api"

zrb/builtin/project/add/fastapp/app/template/src/kebab-zrb-app-name/loadtest/template.env

@@ -1,3 +0,0 @@
-APP_AUTH_ACCESS_TOKEN_COOKIE_KEY=access_token
-APP_AUTH_ADMIN_USERNAME=root
-APP_AUTH_ADMIN_PASSWORD=toor

zrb/builtin/project/add/fastapp/app/template/src/kebab-zrb-app-name/monitoring/clickhouse/clickhouse-cluster.xml

@@ -1,67 +0,0 @@
-<?xml version="1.0"?>
-<clickhouse>
-    <!-- ZooKeeper is used to store metadata about replicas, when using Replicated tables.
-         Optional. If you don't use replicated tables, you could omit that.
-
-         See https://clickhouse.com/docs/en/engines/table-engines/mergetree-family/replication/
-      -->
-    <zookeeper>
-        <node index="1">
-            <host>zookeeper</host>
-            <port>2181</port>
-        </node>
-    </zookeeper>
-
-    <!-- Configuration of clusters that could be used in Distributed tables.
-         https://clickhouse.com/docs/en/operations/table_engines/distributed/
-      -->
-    <remote_servers>
-        <cluster>
-            <!-- Inter-server per-cluster secret for Distributed queries
-                 default: no secret (no authentication will be performed)
-
-                 If set, then Distributed queries will be validated on shards, so at least:
-                 - such cluster should exist on the shard,
-                 - such cluster should have the same secret.
-
-                 And also (and which is more important), the initial_user will
-                 be used as current user for the query.
-
-                 Right now the protocol is pretty simple and it only takes into account:
-                 - cluster name
-                 - query
-
-                 Also it will be nice if the following will be implemented:
-                 - source hostname (see interserver_http_host), but then it will depends from DNS,
-                   it can use IP address instead, but then the you need to get correct on the initiator node.
-                 - target hostname / ip address (same notes as for source hostname)
-                 - time-based security tokens
-            -->
-            <!-- <secret></secret> -->
-            <shard>
-                <!-- Optional. Whether to write data to just one of the replicas. Default: false (write data to all replicas). -->
-                <!-- <internal_replication>false</internal_replication> -->
-                <!-- Optional. Shard weight when writing data. Default: 1. -->
-                <!-- <weight>1</weight> -->
-                <replica>
-                    <host>clickhouse</host>
-                    <port>9000</port>
-                    <!-- Optional. Priority of the replica for load_balancing. Default: 1 (less value has more priority). -->
-                    <!-- <priority>1</priority> -->
-                </replica>
-            </shard>
-            <!-- <shard>
-                <replica>
-                    <host>clickhouse-2</host>
-                    <port>9000</port>
-                </replica>
-            </shard>
-            <shard>
-                <replica>
-                    <host>clickhouse-3</host>
-                    <port>9000</port>
-                </replica>
-            </shard> -->
-        </cluster>
-    </remote_servers>
-</clickhouse>