Estirador

High-level features

Most of the backend and frontend engineering foundations you'll need are already built in estirador's default distribution; with NestJS, Gatsby/React and Bootstrap; from bigger features to small utilities, structures and optimizations

• Hot Reload (no need for a full restart when code is changed: state is kept, code changes are only applied to functions and visual elements):

  • Server
  • Database Migrations
  • Web app
  • Unit Tests
  • Integration Tests
  • Migration Tests

• Test Driven Development

  • Database setup and migrations run on each test suite start
  • Tests are ready to run in parallel, meaning total test run time will be closer to the longest running test, and not to the sum of all tests, as it happens with sequencial tests

• Auditing and compliance

  • Each database row change stores the previous version in the same table, while keeping the referencial integrity of foreign keys for the row that was just updated.
    • No need for maintaining audit tables (tables that are just clones of the real ones) with old entries that also lose referencial integrity with outside tables and always require to have matching columns with a few quirks.
    • Useful for enforcing compliance rules like GDPR and backing services that require data change history
    • Easier to debug errors, since there's a linear history
    • Can rollback a single customer's data to the previous state in case of a bug in production

• Strict backend-frontend integration and data contracts

  Allows you to think of backend and frontend not has two separate projects, but as a single project with features that can be developed atomically (example: a single developer does both backend and frontend in one go)

  • Data structures and validations are shared between backend and frontend as if they were the same project
  • API adapters already deal with API business rules and exceptions like lack of authentication
    • API adapters include type warnings for limitations when data is passed "over the wire" / serialized

      Example: Dates are serialized as strings when send between backend and frontend and the other way around. In the backend, de-serialization of Dates is already dealt with, but on the frontend, the developer needs to manually de-serialize the date and show it in the client's timezone. The built-in API adapters remind the developer that it's not possible to receive Date objects directly from the frontend, and that the values are actually strings that need to be de-serialized. This error is common when typing new endpoints in the frontend, and might make developers lose a lot of time because they're expecting Date objects and forget that it's actually being sent as string.

  • Code sandbox: you can only import code from the backend that is stored in a dedicated shared directory. This avoid accidental import and shipping of code that contains intelectual property

• Update system

  • Most scaffolding boilerplates are a "generate once" trick. You generate the project, but if the boilerplate is improved or fixed, you either have track down the changes and copy and paste them yourself or run code-mod scripts which a lot of times fail if you don't have your code structured in a certain way. Estirador is different, because all updates to it are git commits that can be placed on your project too. Every time estirador implements new tools, features, or fixes, you get them too by just running the update script. You could even take this to the next level and create multiple archetypes or boilerplates for your company, based on estirador. You can have boilerplates for scheduling-based apps, health-care apps, GPS-based apps, payment system apps, etc. and have updates from each of your department's boilerplate be delivered to the apps you own.
  • You can reject updates, or change them to your needs, and not be bothered again for the same update, since the update rejection stays in your project's change history
  • Avoid having deprecated dependencies. Keep them updated in a single place, increment the work everywhere
  • The update system can be detached and applied to any boilerplate repository in any language

• Code split by feature, not by technical layer (like MVC):

  • Our jobs as developers is to translate features into code, hence it makes sense to split the workload by features, and inside the technical translation aka code
  • Its easier to spot where a fix or improvement needs to be done because we know where feature were talking about is
  • Faster to create even more estirador forks, since you can easily spot what features should or should not be included in your new boilerplate
  • Tools and practices come and go. The only constant in your project are its features.

• Common logic like errors and loading states are dealt with automatically

  • Data that goes from backend and frontend and vice-versa has multiple states: loading, refreshing, connection failed, authentication failed, not authorized to load the data, etc. In most app development, the developers have to remember to deal with these multiple states every time they fetch content from a server or remote source, and they implement the same logic, but with different code and in multiple places. With estirador, there's a dedicated data structure for remotely-loaded data, and both the API adapters and gates deal with these states and show a predictable response to the user. No more endless loading screens when the developer forgets to implement error handling in a screen, because everything is taken care for

• Two-token based Authentication protected against common attacks is implemented, as well as the necessary basics for Authorization and user roles

  • The first token is an ID of the session, sent in the login response body, and should be used and stored as a flag for the application to recognize if the user is logged in on not when the app starts (and then check if the token is still valid). The second one is the key to unlock the session. It's sent as an httpOnly cookie, that is inaccessible by Javascript (hence, protecting it from malicious third-party scripts that try to read it) and only sent by the browser when doing a request. You need both to be successfully authenticated. If you want to log off, you can do it even offline (something very difficult to do with httpOnly cookies, because they're not accessible to the application itself, only for outgoing browser requests), by just erasing the first token from the browser's local storage, leaving the second one, which is now useless without the first one. This second token with the session key will then be replaced in the future by another user login.

• Designed for Typescript, with Graphql generator for Gatsby

• Accessibility warnings

  • Like warnings that enforce the use HTML entities instead of the reserved characters

• Eslint and Prettier setup

• Automatic documentation of endpoints with Swagger and reflection

Low-level features

Frontend-specific features

• Lazy loaded reducers with type-safety to avoid dispatching actions to reducers that haven't been loaded yet
• Dark-mode and automatic text contrast detection:
  • dark-mode that isn't just an inverse blend filter and doesn't need specific color classes. In fact, you don't need to use absolute colors in almost everything. Most CSS color classes point to a color meaning (primary, danger, body, etc.) and based on the background around, they pick the best contrasting color for the text. If you're a developer, think of it as a polyfill for color-contrast() (example: the primary color might be dark blue, so you write text with the text-white CSS class. But what if there's a rebranding or a new requirement asks for multi-tenancy branding? You would have to need to change every text color reference. But not with Estirador and its Bootstrap integration)
• Routing and authentication already integrated:
  • If a page does not require authentication, it will be server-side rendered. If it does, it will be client-side rendered, but only after fetching the current session, or terminating a session that expired.
• Gatsby setup as main framework. Since it renders static content, any pages that does not have authentication or AJAX requests have its contents pre-rendered and ready to be consumed by search engines and link previewers like Facebook Open Graph and LinkedIn. Perfect for startups that need a landing page and an authenticated app alongside. It also includes a really code-friendly picture optimizer and cropper: you put the full-quality picture in your source code, and Gatsby will automatically output multiple pictures optimized for each device size.
  • Didn't pick NextJS because server-side-rendering has some concerns that might not be important for the project to start (that do compensate in the future), like minding the scope of the variables so you don't send the previous user's data, and CPU, networking and error handling concerns since it envolves some logic to run, instead of just fetching static files.
• Full Redux state, local storage and session storage cleanup after user logs out

Backend-specific features

• Docker setup
• Environment variables validation

  No more deploy failures or runtime errors due to missing environment variables that were supposed to be set in production, but were not checked for their existance

• Background Jobs compiled as separate files to be able to span multiple workers
• Dev mocks so you don't need to use the real platforms during development
  • Email service mock: why spend email credits when developing when you can use a mock email service that logs and show the emails almost exactly as they are shown in the user's email client
• Error handling
• Settings module: useful for A/B Testing or have settings that come from the back-office
• NestJS: Typescript backend framework that ressembles Spring Boot and provides a lot of documentation and recipes. It has dependency injection, which makes it easy to switch any module implementation depending on the environment and to override the creation of service's instances. It includes a lot of common tools and practices used in backend development. It also has a lot of reflection-based tools like automatic endpoint documentation with Swagger, by detecting class properties and return types, and supports Webpack's Hot Reload