(DRAFT) Pre-Tech Spec: Custom Forms 2.5

draft_rfc_tech_spec_custom-forms-2.5.md

(DRAFT) Pre-Tech Spec: Custom Forms 2.5

ARCHITECTURE

---

As-is Now

Persistance / Backend

Rails + PostgreSQL + JSONB columns (as now)

Use Rails backend to serve JSONB data from PostgreSQL columns...

Pros

• No big architectural changes

Cons

• Non-relational data is hard to serve & maintain from a relational-oriented framework such as Rails (ActiveRecord). Some "hacks" we currently have to do:
  • store_accessor's for JSON fields
  • json_attributes whitelisting

Frontend

Ember + Model Fragments (as now)

Use lytics/ember-data-model-fragments addon in order to use non-relational JSON fragments along with ember-data

Pros

• No substantial changes required

Cons

• Data-binding issues, as ember-data expects a relational data model:
  • See: lytics/ember-data-model-fragments/issues/223
• Might be cumbersome to implement Dynamic models (see comment below)

---

To-be Alternatives

*Note: Most alternatives involve some degree of re-writing current custom-forms implementations.

Persistance / Backend

A. Rails + GraphQL endpoint

Use rmosolgo/graphql-ruby gem to generate an GraphQL endpoint within RoR.

See experimental (working 😁) branch: nimbox-api/experiment/graphql

Pros

• Easy to implement

Cons

• Tightly coupled with RoR

B. PostgreSQL + PostGraphQL

Use an external Postgres "adapter" called PostGraphQL to create a GraphQL independent from the Rails API

Pros

• Auto-schema
• Not coupled with the framework

Cons

• Kinda experimental/PoC

C. Entire new NoSQL persistance layer

Setup a new NoSQL database exclusively for storing custom fields, forms & data.

See original RFC & discussion for further details & options.

Pros

• Freedom to choose NoSQL stack from scratch

Cons

• Setup, maintenance & implementation overhead

Frontend

A. Ember + Model Fragments + GraphQL

Use GraphQL (via alphasights/ember-graphql-adapter) to populate ember-data-model-fragments.

See experimental (not working 😩) branch: nimbox/experiment/graphql

Pros

• No big rewrite

Cons

• Might have same data-binding issues, regardless of using GraphQL

B. Ember + Ember Engines + GraphQL Adapter

Use Ember Engines along with alphasights/ember-graphql-adapter to isolate data access for custom-forms.

Pros

• Isolate data access per module
• Should not suffer from data-binding issues, in theory

Cons

• Ember 2.10 at least required for Ember Engines

C. Ember + Ember Engines + NoSQL Adapter + Flux-like state management

Use Ember Engines along with a NoSQL adapter (ex. ember-mongoose) + Ember Redux to create custom forms

Pros

• Stateless components

Cons

• Kinda experimental stuff
• Ember 2.10 at least required for Ember Engines

D. Entire new View layer

Use an entire new view layer library, such as ReactJS or VueJS, to create custom forms & fields as a separate application, but integrated into Ember

Cons

• Rendering via iframe / black magic

Pro

• Freedom to choose the best single tech for the use-case

Una área que no había tomado en cuenta fue que los modelos Fragments tendrían que ser Dinámicos.

Afortunadamente encontré ejemplos donde se puede hacer esto, aunque haya que hackear un poco el framework. Por ejemplo, ember-admin lo hace: DockYard/ember-admin#82

En este caso crean una store separada llamada store:admin para almacenar en un namespace separado esos modelos dinámicos... en nuestro caso podríamos implementar un store separado store:custom-forms

Desafortunadamente al parecer no es tan sencillo hacerlo con ModelFragments: adopted-ember-addons/ember-data-model-fragments#218

Otra opción es investigar más sobre Orbit.js, específicamente el addon ember-orbit, y de que manera nos puede ayudar a nuestro use-case

Update 27/08/2017

Al parecer no es tan complicado si se usa un IIFE 😄 https://github.com/ecaresoft/nimbox/commit/d81a4638a4dd009e9a99466b3bbb51efce5e02ef