-
Notifications
You must be signed in to change notification settings - Fork 7.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compass App: Add "server" dart shelf-app and "shared" dart package #2359
Conversation
Is our intention to tell people that their server and client model objects should be the same? If so I would recommend against it. Servers generally are running one version of the code but the clients they need to talk to aree running N versions of code where N is the number of app versions you let talk to the server. Generally for apps that number is high. That means that servers need to know about many different versions of the same model object whereas apps need to know about only the model they were compiled with and unexpected new data. I have found that models that assume server and app alignment are practically more fragile than models that explicitly define them differently. This is especially true when your server starts interacting with other servers either owned or external and the model needs to contain information not relevant to clients. Second is the name of the shared model objects. The name should not be Will dig into the code next. |
I agree, as long as we're assuming the target audience for this documentation is enterprise-level app developers, where there is a many-to-many relationship between server apps and client apps. But sharing model objects seems fine/correct for companies/products that have only one server and a few clients, no? If so, the question is, "What application developer are we targeting?" I'm hesitant to assume the correct target audience is developers at Google-size companies with Google-size complexity. I believe we should be targeting the top of the bell curve. |
I also don't think having a shared model between client and server is something app developers should always do. In fact, I'd say it is very rare that a team aligns with the same technology/framework/language/etc. But I think the example responds to the question re. modularization and sharing code between projects. The current Flutter website documentation doesn't cover that (or I wasn't able to find it), and the section regarding package creation is focused on package publishing. I think we can use this example to illustrate something you could do in case you want to share code between different Dart/Flutter projects, and how does it work in practice. We probably don't want to overextend to a complex modular project either. Re: naming of the package. Yes, |
Applied the following suggestions:
More details in the PR description! |
It sounds like you both agree that sharing models isn't practical in the real world. So if we end up sharing code in another way that is more realistic, we should re-evaluate whether we want to share these models. For now, I agree that we want to be able to show sharing code in some way. I'll make a note of this in our doc. For now, I think we can merge this and move on. |
…2359) This PR introduces two new subprojects: - `compass_server` under `compass_app/server`. - `compass_model` under `compass_app/model`. **`compass_server`** - Dart server implemented using `shelf`. - Created with the `dart create -t server-shelf` template. - Implements two REST endpoints: - `GET /continent`: Returns the list of `Continent` as JSON. - `GET /destination`: Returns the list of `Destination` as JSON. - Generated Docker files have been removed. - Implemented tests. - TODO: Implement some basic auth. **`compass_model`** - Dart package to share data model classes between the `server` and `app`. - Contains the data model classes (`Continent`, `Destination`). - Generated JSON from/To methods and data classes using `freezed`. - The sole purpose of this package is to host the data model. Other shared code should go in a different package. **Other changes** - Created an API Client to connect to the local dart server. - Created "remote" repositories, which also implement a basic in-memory caching strategy. - Created two dependency configurations, one with local repositories and one with remote repos. - Created two application main targets to select configuration: - `lib/main_development.dart` which starts the app with the "local" data configuration. - `lib/main_staging.dart` which starts the app with the "remove" (local dart server) configuration. - `lib/main.dart` still works as default entry point. - Implemented tests for remote repositories. - [x] I read the [Flutter Style Guide] _recently_, and have followed its advice. - [x] I signed the [CLA]. - [x] I read the [Contributors Guide]. - [x] I updated/added relevant documentation (doc comments with `///`). - [x] All existing and new tests are passing. If you need help, consider asking for advice on the #hackers-devrel channel on [Discord]. <!-- Links --> [Flutter Style Guide]: https://github.com/flutter/flutter/blob/master/docs/contributing/Style-guide-for-Flutter-repo.md [CLA]: https://cla.developers.google.com/ [Discord]: https://github.com/flutter/flutter/blob/master/docs/contributing/Chat.md [Contributors Guide]: https://github.com/flutter/samples/blob/main/CONTRIBUTING.md WIP implement activity repository local wip activity repository updates and iOS stuff implement navigation logic to activities implement tests fixing navigation with query parameters refactor search queries cleanup and comments cleanup add ItineraryConfig, refactor SearchScreen to use it fix tests refactor with Commands refactor commands add progress indicator to commands simplify command command tests cleanup simplify activity repository cleanup cleanup cleanup fix comment should be Command0 refactor assets, server, and add activities endpoint fix assets refactor wip activities screen add error state to commands Added comments handle errors in Command add comments WIP error indicator widget lifecycle wip activities and error handling Add random errors to repositories to simulate recovering from errors implement activites WIP tests create test activities screen finish Activities UI
This PR introduces two new subprojects:
compass_server
undercompass_app/server
.compass_model
undercompass_app/model
.compass_server
shelf
.dart create -t server-shelf
template.GET /continent
: Returns the list ofContinent
as JSON.GET /destination
: Returns the list ofDestination
as JSON.compass_model
server
andapp
.Continent
,Destination
).freezed
.Other changes
lib/main_development.dart
which starts the app with the "local" data configuration.lib/main_staging.dart
which starts the app with the "remove" (local dart server) configuration.lib/main.dart
still works as default entry point.Pre-launch Checklist
///
).If you need help, consider asking for advice on the #hackers-devrel channel on Discord.