If we want to get closer to having an API based application, we need to stop building screens using rails views accessing the rails models. We need to move into the use of the API for every part of the app. Either by having frontend code (like angular) accessing the API (or by having the rails views depending only on the API but not the OFN services or data models). Spree screens are rails views that depend on the underlying model BUT this logic of building on top of the API can be used for all the spree screens that we replace/rebuild to adapt to our needs.
The main argument for this approach is that by doing this we are developing, extending, testing and bullet proofing the OFN API. If we don’t depend on the API to build OFN’s screens, we will not have a working, complete or resilient API in the long-run.
Above I describe option 1 that I call “API first approach”, all views are built on top of the API.
There are 2 other options at least:
- options 2 - we keep building OFN’s screens with a mix of rails views and angular components (using the mix of posting data to the API and using AMS to feed data into angular through the DOM)
- options 3 - we decide we do API first approach ONLY for the FrontOffice. We can keep the BackOffice as it is with our custom views of Spree data, with existing defaced Spree views and also new views copied from Spree BUT we make all FrontOffice views in Angular only and make it only depend on the API.
I think option 3 would be a good balanced approach because this would enable us to keep the complex rails views on the BackOffice/Spree side of things and, at the same time, test the detached approach where the FrontOffice would run on top of the API only. This would also support the development of the API for OTHER front-offices and shops.
In practice, what option 3 would mean is that we would detach the Darkswarm application from the OFN application.
I am raising this question because in my opinion the current approach “option 2” is not sustainable, because the rails code and the angular code is tightly coupled/intermingled and that makes for slower/difficult/error-prone changes that do not support the evolution of the API.
Please let me know if I explained options clearly and what do you think about this decision!