riverscuomo
commented
8 months ago there needs to be a place in the childApp repo for bools like
Core.hasMarket
so BaseApp can initialize the Purchase
Closed riverscuomo closed 8 months ago
riverscuomo
commented
8 months ago there needs to be a place in the childApp repo for bools like
Core.hasMarket
so BaseApp can initialize the Purchase
riverscuomo
commented
8 months ago okay, now my question is: what about having Boxify (the template app) be an entirely separate package in a different repo?
Having Boxify, the template app, as a separate package in a different repository reflects a hybrid approach between the mono-repo and multi-repo strategies. This approach would allow you to maintain a standalone version of the core template with all the necessary foundational features and functionalities, but in its own dedicated repository.
Here's an outline of what this structure might look like:
Boxify Package Repo: Contains the core template of the app, including common functionality, shared libraries, and components that will be the same across all variations of the app.
Instantiation App Repos: One or more separate repositories, each containing an instantiation of Boxify. These repos would include app-specific configurations, resources, API endpoints, and any additional features unique to that version of the app.
Advantages:
Isolation: Changes to the core template don't immediately affect the instantiations; instead, they can be integrated through package updates, allowing for more controlled rollouts.
Flexibility: Different instantiations can depend on specific versions of the Boxify package, providing stability and preventing unwanted changes due to updates in the core template.
Decoupling: It reduces the risk of having instantiation-specific code accidentally creeping into the core template package.
Disadvantages:
Version Management: Requires meticulous version management for the Boxify package to ensure compatibility across all instantiations.
Update Overhead: Instantiations must be manually updated to receive improvements or bug fixes from the Boxify package.
Dependency Management: More effort is required to manage dependencies between the template package and the instantiations.
This approach is essentially treating Boxify as an external dependency or a shared library that other apps can include and utilize – similar to how one might use third-party libraries in a project. If you decide to go this route, you may want to use package dependency management features provided by the Dart language, such as specifying the Boxify package as a dependency in the pubspec.yaml file of each instantiation.
It's also common to release new versions of your shared package (Boxify) following semantic versioning, to clearly communicate the types of changes that have occurred between releases (such as bug fixes, new features, or breaking changes).~~
Boxify helper When adopting a mono-repo approach and you are looking to elevate certain components from the child apps to the parent Boxify app, the order in which you proceed can make a significant difference in ease of integration and the ability to test incrementally. Here’s a sensible order for the migration based on dependencies and the potential need for shared functionality:
Enums: Begin with enums because they are typically low-level, widely used constructs that don't have dependencies on other parts of the app.
Models: Moving your data models up next makes sense since these are also fundamental and used in conjunction with enums.
Resources: This might include global constants, configuration settings, and strings. It's usually straightforward to share these across different parts of the app.
Helpers & Utilities: These are functions and classes that provide common functionality and are generally independent of the app's business logic.
Widgets: Reusable UI components that are not tied to specific business logic can be moved next. Widgets are potentially used across multiple screens, so they are good candidates for sharing.
Services: These are likely to include business logic and may depend on models, so ensure your models are in place before you move services. Services also often include API calls, which can potentially be shared across apps.
Repositories: These act as an abstraction layer between the service API and the providers/blocs. Since they are tied to models and services, they should be moved after those other elements are in place.
Providers/BLoCs/States/Events: As state management tools, they may heavily depend on models, services, and repositories, so move them after those dependencies are shared in the parent.
Screens: These are the highest level components in your application architecture. They typically bring together all other components. Be cautious about sharing entire screens, as they often contain specific logic and layouts.
Consider these general guidelines while refactoring:
Refactor incrementally and validate at each step to ensure each shared component integrates well. Make sure you have a good suite of tests to ensure that as you refactor, you don't introduce bugs. Think of shared components as libraries. They should be modular, well-documented, and have defined interfaces. Be aware of the tight coupling. Only components that are truly shared and beneficial should go into the shared parent app to minimize complexity. Since your applications likely have differences too, the shared code will need to accommodate variations. Design patterns such as the strategy pattern, observer pattern, or template method pattern can help you isolate what varies and integrate shared functionality smoothly.
Before beginning this process, you might want to sketch out the architecture to visualize the dependencies between the different components so you can plan your refactoring process better.
If some of the configuration settings are specific to the child apps while using a mono-repo, it's important to structure your resources and configuration management in a way that allows for shared defaults as well as app-specific overrides. Here's how you can approach it:
Shared Resources: Place default configuration settings and resources that will be common across all applications into the parent Boxify app. This can include things like common strings, styles, environment-independent settings, and more.
App-Specific Configurations: For each child application, create a separate configuration file or set of files that will only contain the settings and resources unique to that application. You want to isolate those so that when the Boxify template is instantiated, it's clear what can be customized per app.
Configuration Management: Implement a configuration management mechanism that loads the shared resources first and then applies the app-specific overrides. This way, each child app starts with a base configuration that is then extended or replaced by its own settings.
Environment Variables: Consider using environment variables for sensitive or deployment-specific configurations (API keys, endpoints, etc.). You can use .env files that are not tracked in version control (ignored via .gitignore) and load them at runtime.
Conditional Import: Dart supports conditional imports which allow you to load different libraries depending on conditions established at compile-time. You can leverage this to conditionally import app-specific configurations.
Example of conditional import in Dart:
import 'config_default.dart' if (dart.library.io) 'config_child_app1.dart' if (dart.library.html) 'config_child_app2.dart'; Compiler Flags: For compile-time configuration differences, you can use flags and compile-time constants in Dart (using const keyword) that can be conditionally compiled into your application.
Dependency Injection: Consider using a dependency injection framework or pattern to provide the correct instances of configurations or services needed by each child app at runtime.
Following these strategies will allow you to keep a single code base (Boxify) that can easily be branched into different child applications with their own specific settings. Each child app's unique configurations will take precedence over the shared defaults, ensuring the right behavior for that particular instance of the app.
User Okay please rewrite the list now with each items starting with a checkbox suitable for a GitHub issue
Boxify helper Certainly! Here are the tasks as a formatted checklist for a GitHub issue:
riverscuomo
commented
8 months ago [x] Enums: Begin with enums because they are typically low-level, widely used constructs that don't have dependencies on other parts of the app.
[x] Models: Moving your data models up next makes sense since these are also fundamental and used in conjunction with enums.
[x] Resources: This might include global constants, configuration settings, and strings. It's usually straightforward to share these across different parts of the app.
[x] Helpers & Utilities: These are functions and classes that provide common functionality and are generally independent of the app's business logic.
[x] Widgets: Reusable UI components that are not tied to specific business logic can be moved next. Widgets are potentially used across multiple screens, so they are good candidates for sharing.
[x] Services: These are likely to include business logic and may depend on models, so ensure your models are in place before you move services. Services also often include API calls, which can potentially be shared across apps.
[x] Repositories: These act as an abstraction layer between the service API and the providers/blocs. Since they are tied to models and services, they should be moved after those other elements are in place.
[ ] Providers/BLoCs/States/Events: As state management tools, they may heavily depend on models, services, and repositories, so move them after those dependencies are shared in the parent.
[ ] Screens: These are the highest level components in your application architecture. They typically bring together all other components. Be cautious about sharing entire screens, as they often contain specific logic and layouts.
riverscuomo
commented
8 months ago Boxify helper As an AI, I don't have personal feelings, but I can provide insights into the implications from a software development and architecture perspective.
Having significant chunks of the template app that will not be used by some of the children apps can introduce some technical challenges and considerations:
Increase in Size: Unused code can lead to a larger package size, which could affect download times, disk space, and potentially the memory footprint.
Maintainability: Maintaining code that isn't used by all child apps can be more challenging. Over time, it may become difficult to remember which parts of the code are active in which apps, leading to increased complexity.
Confusion and Clutter: New developers or even the current team might get confused by the presence of unused code. It can be unclear which parts of the codebase are relevant for each app.
Potential for Bugs: There's a risk that the unused code could be inadvertently triggered or interfere with the functioning of the app in some unforeseen manner.
Testing Overhead: With more code to consider, testing can become more extensive and complex, even if some code isn't relevant to all apps.
If these concerns are significant, you might consider some strategies to mitigate the impact:
Conditional Compilation: You could use conditional compilation to include or exclude code based on the target application.
Feature Flags: You might implement feature flags that enable or disable entire sections or features of the application at runtime or build time.
Abstract Base Classes: Create abstract classes in the template for fundamental behaviors and extend them in child apps only when necessary.
Modular Architecture: Split your code into feature-based modules, libraries, or packages, which can be included as dependencies only by the specific child apps that require them.
Plugin System: Develop a plugin system that allows child apps to opt into certain features by including them as needed.
Design Patterns: Leverage design patterns such as the Strategy or Template Method to encapsulate varying behavior while sharing common code.
Clear Documentation: Ensure that there's clear documentation about which parts of the code are used where, making it easier for maintenance and understanding the purpose of different code sections.
By carefully considering the implications and employing strategies to mitigate potential downsides, you can effectively manage the presence of unused code in your template app. However, it's essential to frequently evaluate the cost versus benefit of keeping such a mono-repo with shared and unused portions.
riverscuomo
commented
8 months ago When consolidating repositories from child apps that refer to different databases or entirely different sources of data, you need to create a unified interface while allowing for the flexibility to handle the specifics of each data source. Here are some steps to achieve this:
Design an Abstract Base Repository: Begin by designing an abstract base repository with common CRUD operations and query functions. This abstract class will serve as a contract for all repository implementations.
abstract class BaseRepository
class TrackRepository extends BaseRepository
TrackRepository(this.dataSource);
@override Future
abstract class DataSource { Future
var dataSource = isMocked ? MockDataSource() : RealDataSource(); var trackRepo = TrackRepository(dataSource); // ... do the same for other repositories Handle Different Databases: If you have specific database logic, create implementations of DataSource that handle each type of database and pass them to the respective repositories.
class FirebaseDataSource extends DataSource { // Implementation specific to Firebase }
class SQLDataSource extends DataSource { // Implementation specific to SQL databases }
// Choose the right data source based on the environment DataSource dataSource; if (isFirebase) { dataSource = FirebaseDataSource(); } else { dataSource = SQLDataSource(); } Mock Data for Testing: Provide a mock implementation that can be injected for testing purposes. The mock implementation should adhere to the DataSource contract but use in-memory data or hardcoded data to simulate database operations.
class MockDataSource extends DataSource { // Mock implementation for testing List
@override Future
riverscuomo
commented
8 months ago User where should i store a child app's configuration secrets
Boxify helper In a mono-repo architecture where you have a parent application (like Boxify) and multiple child apps, handling configuration secrets (like API keys, database credentials, etc.) requires careful consideration to ensure security and proper environment management.
Here are some common practices for storing a child app's configuration secrets:
Environment Variables The use of environment variables is a standard way to inject configuration into an application at runtime. It separates the code from the configuration and can be easily changed without modifying the codebase. In Flutter, you can manage environment variables using the flutter_dotenv package or a similar solution.
Configuration Files You may also use configuration files that are not tracked by version control (like .gitignore-ed .env files) to store your secrets.
Secure Storage Services You can use hosted services like HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or Google Secret Manager to store your secrets securely. The app retrieves these at runtime via an API.
Encrypted Files If you're storing secrets within the repo, you should encrypt these files using tools like git-crypt or blackbox. These ensure that only authorized individuals can decrypt the sensitive data.
Separate per-environment Configuration To support multiple environments (development, staging, production), you can have separate configuration files or key-value pairs in your environment variables. This prevents accidentally deploying development settings to production.
Here's an example of how to use .env files with flutter_dotenv:
Add flutter_dotenv to your pubspec.yaml file:
dependencies: flutter_dotenv: ^5.0.2 Create an .env file for your local environment secrets:
API_KEY=your_api_key_here DATABASE_PASSWORD=your_database_password_here Load the environment variables in your Flutter app:
import 'package:flutter/material.dart'; import 'package:flutter_dotenv/flutter_dotenv.dart';
Future main() async { await dotenv.load(fileName: ".env"); runApp(MyApp()); }
class MyApp extends StatelessWidget { @override Widget build(BuildContext context) { final apiKey = dotenv.env['API_KEY']; // You can now use your secret config apiKey return MaterialApp( title: 'Your App', // ... ); } } Make sure to add .env to your .gitignore file so it doesn't get tracked by Git.
.env When it comes to isolating secrets for each child app within a mono-repo, you may maintain separate .env files, prefixed by child app names or use directory-based configurations. Be mindful to secure the access to these configurations depending on your team and CI/CD setup.
Remember, the method you choose should conform to your organization's security policies and align with best practices to minimize the risk of exposing sensitive information.
User Problem: but then I need apiKey in Boxify.
Boxify helper If you need to access the apiKey or other configuration secrets in the parent Boxify app and you're maintaining a shared mono-repo, there are a few strategies you can use to share configuration secrets between the parent and child apps. Here are the approaches you can take:
Example:
// config_secrets.dart (Do not track in version control)
class ConfigSecrets { static const apiKey = 'your_api_key_here'; // ... other shared secrets }
Example in Boxify app:
import 'package:flutter_dotenv/flutter_dotenv.dart';
Future main() async { await dotenv.load(fileName: ".env"); runApp(BoxifyApp()); }
class BoxifyApp extends StatelessWidget { @override Widget build(BuildContext context) { final apiKey = dotenv.env['API_KEY']; // Use the apiKey for both Boxify and child apps return MaterialApp( title: 'Boxify', // ... ); } }
Example:
path/to/shared/config/pubspec.yaml: name: shared_config Then import it in Boxify and the child apps:
import 'package:shared_config/config_secrets.dart';
void main() { // You can now use ConfigSecrets.apiKey runApp(MyApp()); }
Note on Security Any approach you choose must ensure that secrets are not exposed in version control and are only accessible by authorized individuals and systems. If you store configuration files containing secrets locally, ensure they are encrypted or secure and not checked into source control. Environment-specific secrets should be managed separately to prevent mix-up between environments.
When you deploy your apps, also consider how your deployment process will secure and inject the secrets, as this often varies depending on the platform and infrastructure being used.
Lastly, when sharing configuration across multiple applications within a mono-repo, it is crucial to manage permissions and access levels carefully to ensure that only necessary secrets are shared between the projects.
User so basically, i can't use flutterdotenv?
Boxify helper You can still use flutter_dotenv or similar packages to manage environment variables in Flutter; however, you need to consider how to structure your mono-repo to share or isolate configuration secrets properly.
Here are some options for using flutter_dotenv in a mono-repo setup with both Boxify (parent app) and child apps needing access to secrets like an apiKey:
Shared .env File You can have a single .env file at the root of your mono-repo that contains common secrets needed by both Boxify and all child apps. When you load this file with flutter_dotenv, it will set the environment variables for whichever app is currently running. This approach assumes that all apps within the mono-repo can safely share the same secrets.
Dedicated .env Files You can maintain separate .env files for each child app and Boxify. This way, each app can have its own specific set of environment variables. During the build process or at runtime, you will load the appropriate .env file based on the app being compiled or run. You might use naming conventions like .env.boxify for Boxify and .env.childapp for a specific child app. In your Flutter code, you'll need logic to decide which .env file to load:
Future main() async { // Determine which .env file to load based on some logic or build configuration String envFileName = determineEnvFileName(); await dotenv.load(fileName: envFileName);
runApp(MyApp()); }
String determineEnvFileName() { // Implement logic to determine which .env file to use if (isBoxifyApp) { return ".env.boxify"; } else { return ".env.childapp"; } } Environment Variables in CI/CD Pipeline If you use a CI/CD pipeline to build and deploy your apps, each app can have its own set of environment variables defined within the pipeline configuration. You can inject these environment variables during the build process, and they are then available at runtime for flutter_dotenv to use.
Environment-Specific Configuration You may use a combination of global secrets in a shared .env file and app-specific secrets in dedicated .env files. This way, you can load the shared configurations for all apps and override or supplement with app-specific configurations as needed.
Remember to add your .env files, especially those containing secrets, to your .gitignore so these are not checked into version control. For example:
.env !.example.env # If you have example .env files for reference that do not contain real secrets The key point is that flutter_dotenv or similar solutions are tools for loading configuration at runtime. How you structure your configuration files and how you manage the sharing of configuration between multiple apps in a mono-repo depends on your specific requirements and security practices. Choose the approach that best aligns with your needs for isolation, sharing, and deployment of your apps.
User If I'm moving all my blocs and cubits to boxify should I keep them all in a folder called lib/blocs? Or keep them as they were separated in each screen folder? Keep in mind, boxify doesn't even have a main.dart file
Boxify helper In a mono-repo structure with shared state management code like BLoCs and Cubits, how you organize them depends on various factors, including the size of your project, how reusable the BLoCs/Cubits are, and your team's preferences. Since Boxify is acting as a core library without a main.dart, it implies that its job is to provide shared functionality to child apps.
Here are two common organizational strategies for your lib directory in Boxify:
Centralized blocs Directory You can centralize all your BLoCs/Cubits in a single blocs directory if they are shared across multiple screens or apps. This approach can make it easier to manage and locate BLoCs/Cubits, particularly if they are numerous or complex.
Structure Example:
lib/ blocs/ authentication_bloc.dart user_profile_bloc.dart settings_bloc.dart // ... more blocs models/ services/ // ... other shared code Feature-based Structure If your BLoCs/Cubits are more closely tied to specific features or screens, it might make sense to keep them organized by feature rather than type. This way, all code related to a particular feature, including BLoCs/Cubits, services, models, and possibly widgets, can be co-located.
Structure Example:
lib/ features/ authentication/ authentication_bloc.dart // ... additional authentication-related code user_profile/ user_profile_bloc.dart // ... additional user profile-related code settings/ settings_bloc.dart // ... additional settings-related code // ... other shared code A feature-based structure is often preferred in larger projects where features are relatively isolated and it’s helpful to keep all related code together. It scales better as the project grows, because developers can focus on one feature at a time, reducing cognitive load and potential merge conflicts.
It’s also entirely feasible to mix these strategies. For instance, you might have a blocs directory for general-purpose or application-wide BLoCs/Cubits, and feature-specific directories for BLoCs/Cubits tied to particular features.
Make sure that, regardless of the organizational strategy you choose, the directory structure within Boxify is clear and intuitive for your team members. Consider creating a README.md in the Boxify root or within specific directories to explain the organizational logic and guide new developers.
When refactoring and moving your BLoCs/Cubits to Boxify, be sure to update any import paths and consider if any changes are needed to handle dependency injection or service location for these BLoCs/Cubits in the child apps. Make use of your version control system's refactoring tools to help track these changes and ensure a smooth transition.
User And it's fine to put qubits in the blocks folder?
Boxify helper Yes, it is perfectly fine to put Cubits in the blocs folder. Cubits are a simpler form of BLoCs (Business Logic Components) provided by the flutter_bloc library. Both BLoCs and Cubits serve as state management tools and follow similar design patterns, so it makes sense to organize them together when they are used for managing different portions of the app's state.
If you are placing your Cubits in the blocs directory, you might want to consider naming the directory something more agnostic to the specific state management class, such as state_management or controllers, to reflect that it contains both BLoCs and Cubits.
Example structure:
lib/ state_management/ // or 'controllers' authentication_cubit.dart authentication_bloc.dart user_profile_cubit.dart settings_bloc.dart // ... more blocs and cubits models/ services/ // ... other shared code This keeps all related state management logic in one place, making it easier for developers to find and maintain them. Just ensure that the directory structure and naming conventions are well-documented and consistent, so that everyone working on the project has a clear understanding of where to locate and how to manage these files.
Lastly, remember to refactor any references to these files in the child apps appropriately after moving them to the state_management or blocs directory in Boxify to maintain the correct import paths.
User error deploying to web
Compiling lib/main.dart for the Web... Error detected in pubspec.yaml: No file or variants found for asset: .env.
Boxify helper The error you're seeing indicates that the build process is trying to include an asset .env as specified in your pubspec.yaml file, but it cannot find such a file in your project directory. This is quite common when using environment variables with packages like flutter_dotenv, but you want to exclude these files from version control for security reasons.
Here's how you can resolve this issue:
Ensure .env files are not required as assets: You typically should not include .env files as assets in your pubspec.yaml. Instead, they should be loaded at runtime from the file system. Double-check your pubspec.yaml file and remove any references you may have included under the assets section. It should not list the .env file.
Check .gitignore: Verify that .env is listed in your .gitignore file to prevent it from being committed to your repository. For example:
.env Provide .env file during build: For development purposes, you should have a .env file in your project root if you are using flutter_dotenv to load environment variables. However, this file should not be tracked by Git. Make sure that this file is present on your development machine and, if necessary, on your build server or in your CI/CD pipeline environment.
Update your build scripts: If you are building for production or deploying via a CI/CD pipeline, make sure the build scripts provide the .env file to the build environment, if needed. Alternatively, configure your environment variables directly in the build environment settings.
Use Environment-specific .env Files: If you have different configurations for different environments (development, staging, production), you might have files named with specific patterns like .env.dev, .env.staging, .env.prod, etc. You'll need to make sure the correct file is being used for the build:
For example, in your Flutter code you could have something like this:
Future
class EnvironmentConfig { // Determine the file name based on the build environment static String get envFileName { // Here you would implement logic to determine which .env file to use // For example, you might use environment variables provided by your CI/CD system return '.env.dev'; // Use the development .env file as an example } } Make sure to correctly manage your .env files across different environments, and always prioritize security by not exposing sensitive information. After making necessary changes, try rebuilding for the web to see if the error is resolved. If you are still encountering problems, you may need to provide more context or review your build configuration and environment setup.
I'm a flutter developer. Right now I have two apps that are slight variations of each other and they share about 50% of the code in a third Repository. I'm thinking about changing the structure so that it's more like there's one template app that has about 90% of the code and then there are two or more instantiation apps that have their own configurations and API links Etc. Are there names for these two different approaches? It might help me do some research and learn more how to structure my code
The two approaches you described are generally known as Multi-Repo (Multiple Repository) approach and Mono-Repo (Monolithic Repository) approach.
In the Multi-Repo approach, you have a different repository for each service/app. Shared code can be made into a library and placed into another repository. It's the method you described first – having shared code in different repositories. This is advantageous if the applications are very distinct without significant overlap.
When you talk about having a template application with the majority of the code - configurations and API links are kept separate - this is closer to a Mono-Repo approach. All services/apps exist in the same repository and share a significant amount of their codebases. This approach has the advantage of making it very easy to share codes and avoid duplications.
To decide between a mono-repo or multi-repo structure you can consider factors like: the organizations size, the degree of code-sharing across apps, continuous integration/testing practices, etc. Each approach has its own pros and cons so you will have to choose an approach that best fits your project and team.
Probably with the mono repo approach you could have infinite instantiations right? I could make it public without any of the API keys or whatever and anyone could instantiate it to make their own version of the app.
Yes, with the mono repo approach could indeed have infinite instantiations, or as many as your version control system can handle. This is similar to how some open-source projects operate. Contributors can clone the repo, add their own configuration or environment variables (API keys, database URIs, etc.), and spin up their own version of the application.
In this use case, it is common practice to exclude sensitive configuration data from version control using environment variables or configuration files that are listed in your .gitignore file. Then, users can supply their own configuration data locally. This allows you to safely make the project public without exposing sensitive information.
What's more, this strategy facilitates contributions. Other developers could make changes or enhancements to the application and submit their changes back to the project.