From a42898fa786263df6e33372a5b1fa0b5f421a362 Mon Sep 17 00:00:00 2001 From: virkt25 Date: Tue, 21 Aug 2018 12:42:13 -0400 Subject: [PATCH] docs: explain express in crafting loopback 4 --- docs/site/Crafting-LoopBack-4.md | 82 +++++++++++++++++--------------- 1 file changed, 44 insertions(+), 38 deletions(-) diff --git a/docs/site/Crafting-LoopBack-4.md b/docs/site/Crafting-LoopBack-4.md index c04258dae65f..3e4d04b80cc5 100644 --- a/docs/site/Crafting-LoopBack-4.md +++ b/docs/site/Crafting-LoopBack-4.md @@ -421,44 +421,50 @@ independent of the nature of such artifacts. need to have a packaging model so that extension developers can create their own modules as bundles and plug into a LoopBack application. -### Why not Express? - -Do we need to build our own core foundation? Can we continue to use Express? Our -conclusion is no. Here are the gaps between what Express and LoopBack's needs. - -- **Lack of extensibility**. - - Express is a routing and middleware web framework with minimal functionality - of its own: An Express application is essentially a series of middleware - function calls. For details, see - [Using middleware](http://expressjs.com/en/guide/using-middleware.html). - - Express is only extensibile via middleware. It neither exposes a registry nor - provides APIs to manage artifacts such as middleware or routers. For its - purpose, Express only deals with middleware-like extensions that intercept - http requests/responses. LoopBack needs much more extension points and - extensions. - -- **Lack of composability**. - - Express is not composable. For example, `app.use()` is the only way to - register a middleware. The order of middleware is determined by the order of - `app.use`. This simplistic approach works for a single monolithic application - where all middleware are known and arranged ahead of time. But it does not - support the case when middleware from other components need to be added - between existing ones. LoopBack had to introduce a phase-based extension and - hack Express to provide this capability. - - Express doesn't provide any way to manage dependencies between artifact - instances either. - -- **Lack of declarative support**. - - In Express, everything is done by JavaScript code as it works exactly as the - web site claims: `Fast, unopinionated, minimalist web framework for Node.js`. - In contrast, LoopBack is designed to facilitate API creation and composition - by conventions and patterns as best practices. More types of constructs are - introduced. +### Why Express behind the scene? + +#### Background + +LoopBack had always been built on Express so we can leverage the vast community +and middleware in the Express ecosystem **BUT** it presented some challenges for +LoopBack. With LoopBack 4 we considered moving away from Express (and even built +the framework without Express) but eventually circled back to Express because of +its vast ecosystem. + +Some of the gaps between what Express offers and LoopBack's needs are: + +- Lack of extensibility + > Express is only extensibile via middleware. It neither exposes a registry + > nor provides APIs to manage artifacts such as middleware or routers. +- Lack of composability + > Express is not composable. For example, `app.use()` is the only way to + > register a middleware. The order of middleware is determined by the order of + > `app.use`. +- Lack of declarative support + > In Express, everything is done by JavaScript ... In contrast, LoopBack is + > designed to facilitate API creation and composition by conventions and + > patterns as best practices. + +#### Circling back to Express with a twist + +The main purpose of LoopBack is to make API creation easy, interacting with +databases, services, etc., not middleware for CORS, static file serving, etc. We +didn't want to reinvent the wheel by writing new middleware for LoopBack 4. + +The team explored leveraging +[Express or Koa](https://github.com/strongloop/loopback-next/pull/1082) (but +only for their middleware support). The final decision was to use Express in a +way that bridges the gap by addressing the gaps identified above as follows: + +- LoopBack provides its own + [Controller / OpenAPI metadata optimized routing engine](Routes.md) +- Express is used exclusively for allowing us to consume Express middleware + (CORS, Static File Serving) +- LoopBack uses a [Sequence of Actions](Sequence.md) to craft the response in a + composable manner and leverages `@loopback/context` as a registry. + +You can learn more details in our blog post on +[improving inbound http processing](https://strongloop.com/strongblog/loopback4-improves-inbound-http-processing). ## Deep dive into LoopBack 4 extensibility