Skip to content

RFC Engineer the engine dev experience wrapper built with the engine itself

Jump to bottom
Adam Yahid edited this page Sep 7, 2020 · 1 revision

Why

There are several reasons for wanting to break the development server out of the engine itself

  1. It implicitly turns our dashboard from a simple react app into an engine feature, allowing us to scale the implementation using the capabilities we are use to getting from the engine
  2. It allows us another internal use case for engine, which will improve our understanding of potential use cases
  3. It makes sense from an architectural point of view - engine is responsible for production build and runtime, engineer is responsible for developer experience such as development servers, incremental builds and whatever future cases we would want of interacting with engine

Inspiration

My main inspiration for the architecture was that of webpack and webpack-dev-server, one package is responsible for webpacks main functionality, the other is for enabling a rich dev experience around it's interface. It prevents leaks in the abstraction, and allows each to be extended if needed without worrying about breaking the other.

DoD for p1

  1. No external API changes for build/production
  2. engineer start should have all of engine start capabilities, with the same CLI interface, the only external change would be engineer instead of engine - this could be aliased internally to prevent breaking changes
  3. Dashboard will be conditionally hooked in
  4. engineer would be an engine app, and other than Application and it's helpers, would only use the public API of the engine
  5. engine-dashboard would be removed from scripts and be part of the gui feature in engineer
  6. engine-dashboard to communicate with the running application via communication instead of http APIs
  7. engine-dashboard would be migrated to a wcs like architecture - perhaps p2?

Proposed solution

The app would consist of 2 features, gui and build, living in 2 environments, a window - engineer-main (so not to collide with users main) and a node environment - build. buildFeature: { build: responsible for analysing the projects features, setting up a node env manager, setting up a webserver with webpack-dev-middleware for each of the users configs. It exposes a proxy to the engine accessible from remoteEnvironments, a slot for providing webpack configs, which should be limited to build env since webpack configs are not serialisable, and the CLI params } gui: { build: registers the dashboard webpack config to the build feature slot, main: renders the engine-dashboard component }

Constraints

  1. WS Communication with node environment launched via runNodeEnvironment is a missing capability in the engine, "hacking" around the communication a bit is required, however it can be done using public APIs, perhaps we should consider adding that capability to the engine\
  2. Since the app start from a node environment which launches a web server, and we want to ability to plug in additional webpack configs via slots (To separate between the dashboard webpack to the gui feature in engineer and not hijack the users web env), we are currently limited to one engineer "view mode" at a time - currently and for the foreseeable future that should remain the case, so we can live with that constraint
Clone this wiki locally