search

nstudio / xplat

Cross-platform (xplat) tools for Nx workspaces.
MIT License
366 stars 52 forks source link

quick thought #117

Closed jeremy-coleman closed 5 years ago

jeremy-coleman commented 5 years ago

hi friends,

just wanted to share a couple thoughts on architecture, bc seems you guys like to think about it.

1) xplat folder structure is great imo , i think within the xplat folder, the structure of how theia ide and vscode are setup is a killer combo.

2) file systems don't have to be trees. a 'tagged' file system browser with a backing flat list of files i think would fix so many problems. (and contribute to making packaging/distribution way easier). difficult-ish to implement. The purpose would be to just create views of your current scope of work - similar to a vscode workspace but multi-dimensional and on-the-fly. kind of like , u know when angular/redux best practice switched from monolith store to feature store? it could easily be both at the same time

3) the big one here. package.json's and node modules are a plague. you can run a script and see your dependencies, monorepos with more than 1 node_modules are unnecessary and create a huge overhead for literally no reason at all. almost everything related to packaging and bundling makes no sense at all for the goal of distributing web applications.

4) bundlers suck. devs need something to concat files and merge dependencies. that AND ONLY that. without transpiling typescript and definitely skipping all external resolution. the web doesn't even support importing from some path like 'react' it has to be an absolute uri or relative, so there's literally NO point in trying to resolve it just concat merge and replace it later.

5) xcloud - similar to xplat client, xcloud folder for the backend

6) embrace abstract classes/interfaces and tooling associated with it for x* modules

NathanWalker commented 5 years ago

Hi @jeremy-coleman thanks for sharing and much appreciated on the kudos.

Regarding 3. - only thing there is when you need per app dep control. Example: Root of workspace may specify majority of all dependencies which work throughout all apps however may you run into situation where one dep for whatever reason is needed in a particular app. Being able to still control dep's for a single app without it affecting others is nice. This happens with {N} apps for instance in workspace where one may need to target a certain dep version for particular reasons.

Any change to current setup that you'd suggest?

jeremy-coleman commented 5 years ago

on the #3 bit, i think just installing side-by-side versions while you refactor is best practice and import them as the alias. ie: import React from 'react-v15'. control+f is easy enough. having everything in one place has so many other benefits, immediate security patches, dependable upgrades and integration tests, etc.

no suggestions other than an xcloud / xwhatevername structure. i think it'd be good for a few big use cases. basically anyone creating an app that is targeted to businesses will need to provide integrations for aws, azure and gcloud at the least. really the exact problem you're fixing on the client could be organized for backend services.

I did see a cool library rxdi, which could replace nest and angular for shareable DI code with semantics close to both. link here https://github.com/rxdi/starter-client-router-preact . Thats a hard sell though bc of integrating with angular's di - no idea how that'd work