Sunday, September 20, 2020

v1.1.0 - Refinement

 While it has only been a few months since our 1.0.0 release, the hits keep coming.  This release is somewhat more constrained than previous ones.  The primary features found in this release are:

  • @travetto/pack is a new module that supports packing applications. 
  • The @travetto/email-template development UI has been externalized into the VSCode Plugin.  Additionally some other enhancements have been made to the templating process.
  • @travetto/cache now supports DynamoDB as a valid storage model
  • @travetto/app has disconnected itself from the rest module and is now a standalone service, when desiring to run the application via the app module.
  • @travetto/rest-fastify properly supports running a lambda context using the aws-lambda-fastify module.  

@travetto/pack

When deploying applications with Travetto, producing the final deployable bundle can be tricky.  Given that the framework does not produce JS as an output, the standard build tools do not normally apply.  This is where the pack module comes in.

The pack module knows how to work with Travetto applications, and what to include versus what not include, with support for targeting production mode where the source should be readonly.

The extended benefits of pack come in the form of being able to target additional npm modules and control how they are packaged.  By default the pack module follows some pretty sensible defaults, but can easily be extended when trying to eek out the smallest bundle size possible.  

You can read more about the module over on our doc site:  https://travetto.dev/docs/pack.

@travetto/email-template

Authoring

Previously, the email template module included a small web server for displaying content.  The implementation was generally somewhat fragile, and was not in line with the development model the Travetto framework seeks to uphold.  To that end, the template authoring functionality has been integrated within the Travetto VSCode Plugin.  The plugin automatically knows if you have the email template module installed, and if you are authoring template files (.email.html)

Changes

The recognized extension of the email templates has been renamed to .email.html. This was necessary to properly isolate the file highlighting within VS Code to avoid any potential conflicts with other tools that were relying upon the .tpl.html files.  

Additionally, the template supports two new components that make authoring emails even easier:
  • <title> - This provides the ability to record the desired subject for the email in a single file. 
  • <summary> - This allows for specifying the preview text in clients with preview support.

@travetto/cache

Lastly, DynamoDB support has been added to the cache module as an option.  It leverages the TTL support provided by Dynamo to automatically, and cleanly expire data within the cache.  When serving the application from a lambda, this is now a valid option for a cost-effective and lightweight caching mechanism.

@travetto/app

The app module, initially, was an extension of running Restful applications.  As time went on, it grew into it's own feature, without depending on the rest module.  Additionally, as the lambda support has grown greatly for the rest modules, it became clear that assuming the inclusion of the app module was incorrect. 

If the app module's functionality is needed, it will need to be included as a dependency.  Applications can still be run manually, without the app module, but require a little more setup.  The di module has introduced a simple example of what is necessary to run an application without using the module.

Library Upgrades

As is the norm, the framework has upgraded all of it's dependencies to the latest viable version (minus node-forge which required a proper upgrade due to security issues).

As of now, the framework requires Typescript 4.x.x as the transformer has been rewritten to rely on the new APIs provided for creating AST nodes. 

Monday, July 6, 2020

v1.0.0 - Time to Fly

The day has finally come, as we welcome the 1.0.0 release of the framework.  This release has seen a complete internal overhaul of the framework, retaining as much stability in the API as possible.  The end result is that most code from 0.7.x and the 1.0.0-beta will be compatible, but some tweaking will be needed.

New Features
  • The compiler is now type aware (with full type checking support):
    • The transformers now know about interfaces
    • The transformers are able to infer return types, and so they should no longer be explicitly needed for DI.
    • Schema now supports simple types/interfaces for field definitions (also useful for SchemaQuery)
  • Image manipulation is a new package and is no longer tied to the asset service, with additional support for JPEG optimization
  • The docker portion of old Exec module has been moved to the Command module along with command line support for launching dev related resources via docker
  • The program execution part of the old Exec module has been integrated into the Boot module.  This provides basic program execution support across all libraries.
  • The Test  module now boasts a watchable test server, that will listen for changes in test files and automatically re-run them.  This is what is used to power the new vscode plugin implementation.
  • Extensions files are now part of the barrel export, and will throw errors if used without the appropriate import.  E.g. import {SchemaQuery} from '@travetto/schema';
  • Code transformation has been externalized to it's own module.
  • Configuration now hides secret information at runtime when running in prod
  • DI now supports `primary` designation to handle ambiguous situations when multiple candidates are available
  • Production mode is now read only and will ensure code compilation and model changes will not occur at runtime.  This allows the code to run appropriately in read only environments.
  • All watch code is now only applied in dev environments, and is fully externalized to remove performance impact.
  • Email templating rewrite no longer requires loading of SASS and parse5 at runtime.  These are now dev dependencies and reduce the overall memory footprint.  All email template compilation happens at build time.
  • Test execution has been reworked to better handle execution failures and other unexpected issues.

Breaking Changes
The largest breaking changes are related to renaming, and are not functional.  The full list of breaking changes: 
  • The code will now be precompiled on many operations now that all files are needed to appropriately typecheck
  • *Provider / *Store classes have been renamed to *Source .  This to make the  sub-module model consistently named (Asseet, Cache, Identity, Model)
  • The AssetStore methods have been renamed to match the cache model to provide a consistent API for similar functionality.
  • Image manipulation is a new package and is no longer tied to the asset service
  • The Email module has been simplified to only support mustache out of the box.
  • The Email Template module has been overhauled.  It is now a template compiler and there are command line tools to compile (watch and compile), and the UI for development has been overhauled
  • The Exec module has been dismantled into various module.
  • The Schedule module have been removed, use the node cron package if necessary
  • The Worker module has been simplified, and now supports only one worker input source, with the ability to extend as needed.
  • All ENV variables have been renamed from X to TRV_X  except for DEBUG, and NODE_ENV
  • The app module no longer supports isolated sub-apps, everything is always connected.
  • The auto flag has been removed from the schema module
  • The app cache is now located within the app directory as .trv_cache . Since the command line test run pre-compiles the tests, they use the same cache as well.
  • console.trace is no longer supported by the logging infrastructure, and only debug is affected by DEBUG/TRV_DEBUG 
Whats Next?
After this release, the framework will spend time solidifying and stabilizing.  After a period of stability, the framework will focus on support for:
  • Full text searching - Primarily Lucene.  Now that MongoDB Atlas supports Lucene as a search index, a separate module focusing on full text indexing will allow for better searching.
  • Simplistic Data Stores - Data stores with a subset of features considered to be standard
    • DynamoDB - Cannot paginate, with limited sorting/searching capabilities
    • FireStore - Cannot paginate, with limited sorting/searching capabilities
  • Queues - Support for queue based processing, mainly focused on cloud infrastructure
    • AWS SQS/SNS
    • Kinesis/Kafka
    • Firebase
  • WebSocket support and integration with the REST module