component-rfc.txt

Team Name:
the breakers
the code breakers
splice and slice
devisive
Iron Maidener
DRAGONFORCE II



NITRO TRANSITION COMPONENT - SPLIT MODELS FROM CONTROLLERS/VIEWS
================================================================

Summary
=======

We aim to split the `nitro_component_transition` component into two components: one containing models, and one containing controllers and views.

This will allow us to enjoy the established benefits of Nitro componetization for these two new components:

- Faster test runs because tests can be parallelization
- Faster test runs because only the changed components need be tested (example: if you change a view, the corresponding model need not be tested)

Motivation
==========

The team has nearly unanimously identified test run times (and therefore long deploy times) of ~2 hours as one of the largest obstacles to coder productivity and happiness. The `nitro_component_transition` component, as the largest component, is responsible for the bulk of these long spec/deploy times. At the end of this task, we will have two components each with a test time of ~1 hour.

We can reduce dependency complexity: components that currently depend on the (rather monolithic) nitro_component_transition component can now depend on the relatively svelte $NEW_MODEL_COMPONENT

By reducing test run times for $NEW_CONTROLLER_VIEW_COMPONENT, we will encourage developers to contribute more tests in these areas (areas in which Nitro is currently lacking)

Detailed Design
===============

We believe that by having two components, will result in a better test run time, we will know we have succeeded when tests are running under ~1 hour.

At the end of this iteration we'll have two components: $NEW_CONTROLLER_VIEW_COMPONENT and #NEW_MODEL_COMPONENT

We will not address Rubocop failures for this initial iteration; we'll generate a new Rubocop "todo" file for $NEW_CONTROLLER_VIEW_COMPONENT.

We'll do the initial move in a single branch. Then, we'll observe breakage, and split into teams to tackle the issues that surface.

Script to move models (idempotent)

Have a minimal regression tests (smoke tested by a ninja) to ensure the changes don't break anything.

How We Teach This
=================

We will (via overcommit) prevent users from creating new files in the wrong component (views/controllers in the model component, or models in the views/controllers component, and guide them in the right direction

The components' respective README.md files will guide users

Standard Rails generators will no longer work. If that is a problem in practice, in the future we could modify the stock generators.

Note in the wiki (onboarding guide?)


Drawbacks
=========

- Onboarding new developers used to "standard" Rails applications will require a bit more effort
- Extra cognitive overload associated with split to NCT
- In this initial iteration, the new components will be "weak" in the sense that they don't represent strictly related functionality; they do not solve the root problem that componentization ultimately solves
- How to merge this into master, we have to keep the branch in sync with all the changes happening elsewhere.
-

Alternatives
============

Splitting ONLY the tests into two halves, for parallelization

Rewriting all of Nitro as microservices

NO SQL NO SQL NO SCHEMAS NO MASTERS NO RULES NODE JS SERVERLESS AMAZON S3 EVERYTHING IS A LAMBDAAAAAAAAAAAAAAAAAA 🍸🎉💊 YEAH BRO

Alcoholism

Extracting "strong" components, rather than splitting things in half. We should note that our current approach does NOT preclude the extraction of "strong" components - that is still the ultimate goal. However, extraction of "strong" components is much more time consuming and will not provide short-term relief.


Unresolved Questions
====================

- Our ability to judge the correctness of our code relies upon our test suite. However, our test suite is lacking in places, particularly our controllers.

- If the models rely on helpers, we need to address it in a way that does not involve circular dependency. If the model relies on the helpers in NCT, and NCT relies on the model component, we lose the values of splitting them.


Notes
=====

- Look at Support tickets as guidance (models still in NCT)
- While ideal, we're not namespacing in this iteration
- Do we want to merge it this week? This will create conflicts with almost any opened PR. And there is an impact in the business.




NAMES
=====
The name should:
- be short
- represent as much as possible the intent of the component that will hold the models
-

Proposed Names (In order of preference):

- Core
- CoreModels
- Kernel
- NitroModel

Names that we will NOT propose:

- Data
- NitroSql
- NHibernate
- EntityLAMEwork
- Persistance
- Record