Set up AppVeyor to run CI build on Windows.

This is another frequent request that has come in off-line: an example of an Angular UI talking to a SOAP server.

It would make a good feature in this example program. One of the servers offered should provide a SOAP endpoint, and one of the user interface modules should use a suitable JavaScript SOAP library to call it.

Please

There have been (off-line) requests to make this example application slightly more realistic across the stack, by moving the data displayed out of JSON files (served by a piece of development tooling, json-server) into RDBMS tables.

Most likely choice, PostgreSQL.

Most likely this will involve creating a few tables and a way of populating them with fake data, in the "employee management system" example problem domain used here. Alternatively, if there is some kind of example RDBMS data out there that could be used, it will be possible to edit the problem domain here a bit to match.

Change all the non-ngrx-store features to lazy load their top level route.

This is a feature idea.

The example project already has a server capable of serving a flow of data over a simple SSE "push" channel.

Add a user interface module which consumes this data.

Currently the build with AOT is turned off on Travis, because of this CLI issue:

angular/angular-cli#5986

angular/angular-cli#5998

Either wait for a fix, or work around it. Work around idea: Put a single file module in the app project, which brings in the external package. Route to this little placeholder/ship.

This is a feature idea.

Add:

• example realistic (-ish) server which exposes a GraphQL endpoint.
• example realistic UI module which consumes that.
• use Apollo libraries in both.

Justification:

For a number of years, REST APIs have been the standard most enterprise data system projects aim for. While this has been an improvement over many past practices, it is also been found to not scale very well in terms of system size. In particular, it often leads to manual work composing together different API aspects so that they can be consumed efficiently from a user interface.

GraphQL solves this problem, by raising the level of abstraction.

Issue #1 is about a typical client/server graphQL implementation.

Here is an alternative, worth implementing in a different feature of this gradually sprawling example application:

Implement GraphQL entirely in the client code, talking to a REST backend. This should serve as a nice illustration of usefulness of GraphQL even in systems where the server-side API is already well-established.

This mode of operation is supported by GraphQL, no invention here, just digging around and wiring up the APIs inside an Angular application.

Inside admin folder I ran...

yarn add loaderjs --save
yarn add v0.27.5
[1/4] Resolving packages...
error An unexpected error occurred: "https://registry.npmjs.org/@oasisdigital%2ffruit-basket: Not found".

This happens for any package you try to install. How did you get around this error for adding new packages?

Currently this example does not use the "hoist" mode of Lerna, because Angular CLI unfortunately requires that its dependencies be installed in the immediate, local node_modules directory, rather than using standard node module resolution (which would be possible of finding "hoisted" packages).

angular/angular-cli#3864

I've already made an experimental branch which applies a bunch of symlinks to patch this up.

At some point, either ensure this is reasonably solid and use it, or hopefully see Angular CLI perform standard node resolution so that hoist "just works".

Implement "breadcrumbs" at the top of the screen to reflect the current state of navigation, as is typically seen in nicely polished enterprise applications.

One of the example features and here is a silly, small use of NgRx, to control a fruit basket which spills if too much is put in it.

Make this a bit more visually interesting; but more importantly, replace the old style NgRx code in it with the current recommended style.

Feature idea:

Add a RESTful CRUD example:

• Server, using a library that makes it very easy to create a RESTful JSON API
• UI in front of that server.
• CRUD features - a counter to the numerous examples that only do the "R" in CRUD.

(BTW - I'm a big fan of REST for inter-system APIs, but GraphQL or similar is probably now a better choice for typical web-UI-to-data-server APIs.)

Log:

0 info it worked if it ends with ok
1 verbose cli [ 'C:\Program Files\nodejs\node.exe',
1 verbose cli 'C:\Program Files\nodejs\node_modules\npm\bin\npm-cli.js',
1 verbose cli 'run',
1 verbose cli 'build' ]
2 info using [email protected]
3 info using [email protected]
4 verbose run-script [ 'prebuild', 'build', 'postbuild' ]
5 info lifecycle @oasisdigital/[email protected]prebuild: @oasisdigital/[email protected]
6 silly lifecycle @oasisdigital/[email protected]prebuild: no script for prebuild, continuing
7 info lifecycle @oasisdigital/[email protected]build: @oasisdigital/[email protected]
8 verbose lifecycle @oasisdigital/[email protected]build: unsafe-perm in lifecycle true
9 verbose lifecycle @oasisdigital/[email protected]build: PATH: C:\Program Files\nodejs\node_modules\npm\bin\node-gyp-bin;C:\Projects\github\scalable-enterprise-angular\servers\employee-rest-server\node_modules.bin;C:\Projects\github\scalable-enterprise-angular\node_modules.bin;C:\Users\padam\AppData\Local\Yarn\config\link\node_modules.bin;C:\Projects\github\scalable-enterprise-angular\node_modules.bin;C:\Users\padam\AppData\Local\Yarn\config\link\node_modules.bin;C:\Program Files (x86)\Yarn\bin\node-gyp-bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\ProgramData\chocolatey\bin;C:\Program Files\Git\cmd;C:\Program Files\Git\mingw64\bin;C:\Program Files\Git\usr\bin;C:\Python27;;C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit;C:\Program Files\Microsoft SQL Server\110\Tools\Binn;C:\Program Files\Microsoft Windows Performance Toolkit;C:\Program Files\nodejs;C:\Program Files (x86)\Yarn\bin;C:\Ruby21-x64\bin;;C:\Program Files\Docker Toolbox;C:\Users\padam\AppData\Roaming\npm;C:\Users\padam\AppData\Local\Yarn.bin
10 verbose lifecycle @oasisdigital/[email protected]build: CWD: C:\Projects\github\scalable-enterprise-angular\servers\employee-rest-server
11 silly lifecycle @oasisdigital/[email protected]build: Args: [ '/d /s /c', 'tsc --outDir build' ]
12 silly lifecycle @oasisdigital/[email protected]build: Returned: code: 2 signal: null
13 info lifecycle @oasisdigital/[email protected]~build: Failed to exec build script
14 verbose stack Error: @oasisdigital/[email protected] build: tsc --outDir build
14 verbose stack Exit status 2
14 verbose stack at EventEmitter. (C:\Program Files\nodejs\node_modules\npm\lib\utils\lifecycle.js:279:16)
14 verbose stack at emitTwo (events.js:106:13)
14 verbose stack at EventEmitter.emit (events.js:194:7)
14 verbose stack at ChildProcess. (C:\Program Files\nodejs\node_modules\npm\lib\utils\spawn.js:40:14)
14 verbose stack at emitTwo (events.js:106:13)
14 verbose stack at ChildProcess.emit (events.js:194:7)
14 verbose stack at maybeClose (internal/child_process.js:899:16)
14 verbose stack at Process.ChildProcess._handle.onexit (internal/child_process.js:226:5)
15 verbose pkgid @oasisdigital/[email protected]
16 verbose cwd C:\Projects\github\scalable-enterprise-angular\servers\employee-rest-server
17 error Windows_NT 6.3.9600
18 error argv "C:\Program Files\nodejs\node.exe" "C:\Program Files\nodejs\node_modules\npm\bin\npm-cli.js" "run" "build"
19 error node v7.8.0
20 error npm v4.2.0
21 error code ELIFECYCLE
22 error errno 2
23 error @oasisdigital/[email protected] build: tsc --outDir build
23 error Exit status 2
24 error Failed at the @oasisdigital/[email protected] build script 'tsc --outDir build'.
24 error Make sure you have the latest version of node.js and npm installed.
24 error If you do, this is most likely a problem with the @oasisdigital/employee-rest-server package,
24 error not with npm itself.
24 error Tell the author that this fails on your system:
24 error tsc --outDir build
24 error You can get information on how to open an issue for this project with:
24 error npm bugs @oasisdigital/employee-rest-server
24 error Or if that isn't available, you can get their info via:
24 error npm owner ls @oasisdigital/employee-rest-server
24 error There is likely additional logging output above.
25 verbose exit [ 2, true ]
26 warn Local package.json exists, but node_modules missing, did you mean to install?

It was pointed out to me that at the moment only a small sliver of the Angular community has touched all the right pieces of tooling, for this example repo to make any sense.

Therefore, TODO, make more comprehensive doc or video explaining it.

Initially all of the code in this example runs on Node.

But many enterprise projects, including many that we work on at work, have either a monolithic or micro-service architecture or some or all of the server code is not Node at all.

Therefore, an idea:

Demonstrate with another server included in this example, how non-node code can be integrated. For example, stand up a simple example REST server using Spring Boot (Java). Such a server can be coded in something like 10 minutes (not counting time waiting for Maven...) and would make the example more useful for people working in multiplatform environments.

Our projects with Node servers are usually built in TypeScript, and share some code between client and server...

Expand this example (family of) projects to demonstrate that in action.

Currently this multi-application structure uses NPM packages managed by Lerna in an unusual way: with TypeScript code and no compiled JavaScript. When compiling an application, all of the referenced library code is compiled at that time.

This considerably simplifies and improves the development process, but creates the following unfortunate dependency situation:

Consider the dependencies A -> B, B -> C. Application A must declare a dependency on library C for it to work. This is because B gets compiled in A's context.

There are different possible approaches to eliminate this tedium. Perhaps the easiest would be to simply automate it in place, it would involve only a small amount of logic.

I would love to see some best practices for how to deploy this example, and hopefully be able to address questions similar to the following?

• How would you put this application into a container?
• Would you put each application into its own container?
• Would you separate the servers-side from the front-end?

There is already a way to run Compodoc.

Use gh-pages to easily publish the output to Github Pages.

It would be cool to see an example page/application that uses server-side rendering with angular-universal. It would be interesting to see how that might live with-in the context of the rest of the application.

...or something that uses the AppShell strategy, as enterprise applications sometime need to load to much data initially before it can start rendering a page.

Might not be a real use-case... just an idea.

This example shows how to split a large Angular application into many pieces, managed in a monorepo. Although fairly popular in 2017, there are also many organizations looking to scale their enterprise Angular projects, who don't want a mono repo.

This idea therefore:

Write a script that processes the contents of this repo and automatically splits it into N separate repos. Then patches up the contents of each one to build locally and push to a private NPM repo.

There are serious developer productivity challenges with this approach. It requires that each separate module be developed separately, versioned, published to a private repo before it can be seen and used by other modules. This in turn, more strongly discourages developers from breaking out code in the most modular way.

Still, with the right tooling and advice such an approach should be workable and would be more valuable to some organizations then this monorepo approach.

The example project already uses Store for two different modules that are managed separately and don't depend on each other. An application (in this example, "admin") can statically compose the state for the modules, and make them share the same Store. It works well, but it does not allow lazy loading.

This is because some machinery is necessary in the Store itself to make it possible to dynamically compose reducers in the store as lazy loading occurs.

There is work underway now (April 2017) to enhance Store with this feature. Once that ships, hopefully in May, this example could be updated to use it.

Currently the REST-JSON parts of this example use ad hoc REST implementations. They have a high degree of uniformity (because they have started out using json-server as a backend) but don't follow any particular specification.

Consider using json:api instead:

http://jsonapi.org/

There is both client and server side code available which conforms to the spec. It includes automatically, the various mechanisms needed for inter entity links, sorting and paging, and numerous other conveniences.

Possibly useful tool: https://github.com/abdulhaq-e/ngrx-json-api

(There are complex trade-offs in choosing a client/server API style and spec - although GraphQL is the big new thing and potentially an enormous payoff for some projects, REST still has many appropriate uses.)

All the code currently in here is hand coded.

Add an additional mechanism, which can be run to generate a configurable large number of additional modules, components.

Use this to "bulk up" the code base to somewhere in the size range of the largest known Angular applications.

(Ask around the Angular team to find out what their largest known code size is. Since we don't need to know what or whose application is that size, hopefully this is information that can be obtained and publicly posted.)

This repository shows how to compile and run each application (in a suite of several applications) as a whole, including all of the modules it references. I have in mind a mechanism to include a small amount of boilerplate around each module, and be able to run (not just compile) individual modules outside an app context.

This could greatly speed the development cycle for sprawling applications.

Currently the example application uses Materialize CSS. This works well, but is less realistic for a large app, than something with more functionality.

Change out Materialize CSS for Angular Material (2) or ng-bootstrap.

Add more explanatory comments, and perhaps content in README files, throughout.

Assume that the reader may be somewhat familiar with Angular but not that familiar with the techniques and use.

Point out especially the large gap between what this is meant to represent, and a very primitive functionality currently present.