Compass App: Add "server" dart shelf-app and "shared" dart package

[miquelbeltran]

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.

Pre-launch Checklist

• I read the Flutter Style Guide recently, and have followed its advice.
• I signed the CLA.
• I read the Contributors Guide.
• I updated/added relevant documentation (doc comments with ///).
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-devrel channel on Discord.

[reidbaker]

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 compass_shared because the essence of the package is not that the models are shared but instead the structure of some class of data. If we are going to have an example that uses shared model data then perhaps compass_model_data or compass_model. Then it happens to be that the model data is shared between flutter client and a dart server. The relationship of being shared is something that can change over time.

Will dig into the code next.

[ericwindmill]

Is our intention to tell people that their server and client model objects should be the same?

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.

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.

[miquelbeltran]

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, compass_model sounds good to me. I thought about compass_share assuming we want to share more than just the data model, but we can always create another subpackage for that (and would probably be cleaner).

[miquelbeltran]

Applied the following suggestions:

• Created two target configurations: main_development.dart and main_staging.dart.
• Renamed compass_shared to compass_model.

More details in the PR description!

[ericwindmill]

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.

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.