-- trabe # Building a frontend development framework
-- trabe # Building a frontend development framework (by combining third party frameworks and libraries) -- trabe # Building a frontend development framework (an ES2015/React/Redux based framework) -- trabe who
David Barral
david@trabe.io
@davidbarral
Asís García
asis@trabe.io
@asischao
![](assets/trabe-logo.png)
https://trabe.io
@trabe
-- # Origin ## There was a frontend framework... * Archetype, not framework * Developer dissatisfaction * Versioning hell * Technical debt * Maintenance hell ### ... with low adoption rate -- # Solution ## Develop a new framework * A real framework * DX (developer experience) * Semantic versioning + migration path * Modern technologies * A series of refined design principles and smart decision making xD -- # Problem driven design ## Build a solution for a
real world problem * User-needs driven development * Extract framework from the solution * Avoid synthetic APIs * Caution: it might end being a not ideal solution -- # Problem driven design ## Build a solution for a
real world problem * User-needs driven development ❌ * Extract framework from the solution ❌ * Avoid synthetic APIs ❌ * Caution: it might end being a not ideal solution ❌ -- # Functionality bloat ## It's a "frame"-work! * Support 100% use cases badly instead of solving 80% the right way * Danger of building specific solutions into the framework -- # Functionality bloat ## It's a "frame"-work! * Support 100% use cases badly instead of solving 80% the right way * Danger of building specific solutions into the framework ❌ -- # Focused effort ## Offer the viable minimum * Minimize functionalities * Minimize API surface * Minimize code (less code means less maintenance) -- # Focused effort ## Offer the viable minimum * Minimize functionalities ❌ * Minimize API surface ❌ * Minimize code (less code means less maintenance) ❌ -- # Design ## Favor composition * Small pieces * Provide basic components * Also provide complex components that use the basic ones * SRP * Separate logic from UI -- # Design ## Favor composition * Small pieces * Provide basic components * Also provide complex components that use the basic ones * SRP * Separate logic from UI ❌ -- two-columns # DX ## Be programmer friendly * Guards * Self explanatory errors * Custom tooling * Offline docs * Runnable/Interactive examples * Scaffolding (teach by example) * Explicitness * Convention over configuration * Sane defaults * Extension points * Source code as documentation -- two-columns # DX ## Be programmer friendly * Guards * Self explanatory errors * Custom tooling * Offline docs * Runnable/Interactive examples * Scaffolding (teach by example) ❌ * Explicitness ❌ * Convention over configuration * Sane defaults * Extension points ❌ * Source code as documentation -- # First steps ## No need to reinvent the wheel * Look for base technologies * Analize and build working prototypes -- # Evolution ## Predictable releases * Strict Semantic Versioning * Changelog and migration instructions * Prioritize bugfixing -- # Evolution ## Predictable releases * Strict Semantic Versioning ❌ * Changelog and migration instructions * Prioritize bugfixing -- # Evolution ## Predictable releases * Strict Semantic Versioning ✅ * Changelog and migration instructions * Prioritize bugfixing -- # Evolution ## Avoid technical debt * Update deps often. Handle the breaking changes * Refactor early. Refactor often * Try new technology in sandboxed parts. Experience pros and cons. Adopt if it gives advantages -- # Evolution ## Avoid technical debt * Update deps often. Handle the breaking changes ❌ * Refactor early. Refactor often * Try new technology in sandboxed parts. Experience pros and cons. Adopt if it gives advantages -- # Deprecation ## Have strict/predictable policies * Deprecate early: * Unused stuff * Language supported stuff * Third party better supported stuff ### don't fall for "it's already done!" -- # Dependencies ## Proven solutions only, only if "really" needed * Do not force unnecessary third party deps. Contain both amount and size * Bugs and pull requests * Beware of the update hell. Wrap but do not rewrite. Adapt when needed * Beware: integrating tools not meant to work together -- # Dependencies ## Proven solutions only, only if "really" needed * Do not force unnecessary third party deps. Contain both amount and size ❌ * Bugs and pull requests * Beware of the update hell. Wrap but do not rewrite. Adapt when needed * Beware: integrating tools not meant to work together -- # Code standards ## Remove personal aesthetics from the equation * Standardize a code convention * Enforce with a linter * Use a code formatter -- # Transpilation ## Write future proof code * Use the best tools * Use modern versions * Prevent future technical debt -- # Testing ## No tests, no confidence ## No tests, no refactoring * Integration vs Unit * Snapshot testing * Regression testing -- # Environments ## Build everywhere, run everywhere * Support different major OSs * Support development, staging, production, testing... -- # Source control ## Use a strict policy * Monorepo vs multirepo * Rebase vs merge * Bisect, history traversing * Commit messages -- # CI ## Avoid mistakes and chores * Codebase health check * Automatic release when version changes * Automatic repo tagging -- # Teamwork ## Keep everybody in the loop * Communication * "Getting started" documentation * Automate PR "sanity checks" * Pull requests & (team) code reviews * Tooling: github, bitbucket, gitlab, danger... -- # Teamwork ## Keep everybody in the loop * Communication * "Getting started" documentation * Automate PR "sanity checks" ❌ * Pull requests & (team) code reviews * Tooling: github, bitbucket, gitlab, danger... -- trabe-black # Chapter 2 -- trabe # Building a microservices development framework
-- trabe # Building a microservices development framework (by combining third party frameworks and libraries) -- trabe # Building a microservices development framework (a Node/Koa based framework) -- # Origin ## There was a microservices framework... * Java/Spring boot based * A series of technologies glued together ### ... but no Node.js alternative -- # Solution Develop a new framework * Node/Koa based * Port funcionalities/ideas * Adapt to JS/Node * Modern technologies * A series of refined design principles and smart decision making xD -- # Same principles applied! -- # Learn from the past * Strict semantic versioning * Deprecate all the things * Monorepo + multipackage * Tight control of docs * Alphas + feedback * Clear Roadmap -- # Learn from the past * Strict semantic versioning * Deprecate all the things * Monorepo + multipackage * Tight control of docs * Alphas + feedback * Clear Roadmap ❌ -- trabe-black # That's all folks! ## Questions?