With Strawberry
- Things that affect finishing my cards
Opinion: Things that can affect the delivery and good result
- We need to prevent the use of the REST API in IKE (Pete put that idea, but that is not possible because we are planning to use Strawberry ID (the integer id is encoded))
- About Architecture: We start with MVVM but currently, the
view_model is not independent of the view and the logic there is not possible to use, because we need to import a class from the view. (Pending for EOD example the view_model depends on the view)
- Suggestion: Proof of concept and verify if the architecture work.
- Move the Route Map in the base of estimations
- Lack of BE conventions (BE level)
- Things to improve (Team level)
- The bad: the dashboard could be managed together with the core and thus be able to obtain a real model in a short time, and measure things better.
- The good: The help from Jake, trying to make small releases and move the queries with the test.
In Graphene
- Start the BE and FE before having the Schema, which is one of the 1st rules, allow create the code in FE and BE in the base of this, where more than 70% of the code was deleted.
- In my case, that means more than 1.2k lines were deleted.
- More than 1,9k lines of the logic of the
view_model are pending for merge with the master after pushing strawberry and upgrading with the new conventions (here), if something changes in the requirement maybe this logic can not be util.
- Allow the things without unit or integration test.
- The outsourcing of the graphene, recommends Strawberry which is a bit weird.