More Suggestions

I love where this framework is going. My goal would be to be able to build a full working boilerplate based on FoalTS (with features already suggested over there), alongside a separated “client” / “native” folders containing the frontend for web / native. The latter already have great CLI tools, so i’m looking on the backend side at the moment… After following the 2 first tutorials, i would like to make some suggestions :

@foal/cli is awesome !

• foal createapp : would it be possible to make it like vue-cli which asks a serie of questions. For example, it could ask what user want :

  • which architecture (SPA or SSR)
  • which folders organisation (by type or by functionality)
  • REST or GraphQL
  • which database (PostgreSQL/TypeORM or Mongo/Mongoose)
  • if SSR, which frontend framework to “connect” (hello foal connect ...)
  • which authentication pattern (sessions/cookies or JWT/JWKS)
  • which social auth(s)
  • define roles (by default ‘admin’ and ‘user’)
  • define permission groups
  • include/ignore OpenAPI docs
  • include/ignore VSCode profiles for debugging and testing
  • include/ignore LoggingService
  • Dockerize or not
  • which CI/CD (not sure what you could ask on that one ?)
  • config format (json or yml or .env) => reflect in .gitignore
  • include/ignore Prettier

  Then those questions should help figuring which dependencies to add, and which folder structure and config to write. The generated structure would revolve around a single api example for todolist. There are also functionalities like PasswordReset and Cloud deployment i don’t know how they could/should be integrated.

• foal g rest-api : maybe it would be better renamed as foal createapi or foal add-api to reflect it could potentially add new graphql apis (and not limited to ‘rest’ only)

• foal run my-script : why separate the build ? while following the tutorial, i often forgot that step when running directly foal run my-script. Is there a reason to not integrate the build directly in the run command ?

• foal deploy based on createapp answers would be helpful

• The Simple Todo List tutorial is missing the updating part @Patch('todos/:id') ?

• Is there a way to make the front auto-reload immediately after a server reload ? (annoying to F5 every time XD)

• in package.json, i noticed the migration:xxx scripts use ./node_modules/bin/typeorm => npx typeorm should work ?

• move ormconfig.json and all the tsconfig.xxx.json in the config folder ? This would make the global structure appear less bloated. Config folder could also have 3 folders: development, production and test, plus maybe another folder ‘database’ holding config files for orm, graphql schemas and DBs ?

… pfewww i realize now all that may look overtoomuchaskingforthemoon :S but maybe you’ll find some ideas helping for FoalTS future 🚀

Cheers !

PS: i really appreciated the explanations in both tutorials, clean and concise 👍

[LoicPoullain]

foal createapp

Ok so we maybe could go with something like this:

foal createapp my-app --advanced

1. Which kind of application?
> Regular Web Applications (SSR, Templates, Auth with Redirections, etc)
> SPA + API
> Mobile + API
> API (default)

1a (if SPA + API or Mobile + API or API). API Type?
> REST (default)
> GraphQL

1b (if SPA + API). Which frontend framework?
> Angular
> React
> VueJS

2. Directory architecture?
> By type (default) (controllers/, services/, entities/, etc)
> By functionality (api/, auth/, etc)

3. Which database?
> SQLite
> PostgreSQL
> MySQL
> MariaDB
> MongoDB

4. (multiple-choice question) Which Authentication?
* Email & Password
* Google
* Facebook
* LinkedIn
* etc

5. Access control?
> None
> Admin
> Static roles
> (if database is SQL) Groups & Permissions (advanced)

(1.) Depending on the result, the CLI would add a templates/ directory, run the command foal connect and maybe install a default template engine (all Express-compatible engines will work with version 1) such as twig. If SSR, add a PageController with some routes that use the render function. If API (SPA, API, Mobile), add an ApiController.

(1a.) If GraphQL, install @foal/graphql and graphql

(3.) Install the database driver and configure ormconfig.js and the config/ files.

(4.). Add signup, login and logout routes. The implementation would vary with (1.) results.

(5.) Add properties to the User class and create a hook AdminRequired, RoleRequired, etc.

What do you think on this?

foal run

I think we could do even better and use a configuration key here. For example, settings.scripts.autoBuild. This way, we could add it to the uncommited file .env and still be able to test our production and development environments on local host.

.env

SETTINGS_SCRIPTS_AUTO_BUILD=true

CI/CD, Docker

At some point I was thinking about adding two commands:

• foal g gitlab-config to generate a .gitlab-ci.yml file. This way, when creating a new PR on Gitlab, we would already have a complete CI pipeline working.
• foal g docker-config to generate a Dockerfile. I wonder if this one wouldn’t be a bit complicated due the presence of a database.

Do you find it interesting?

Update

Correct!

npx

Oh I didn’t know! Do you want to submit a PR on this? The files to update would be:

• packages/cli/src/generate/templates/app/package.yaml.json
• packages/cli/src/generate/templates/app/package.json
• packages/cli/src/generate/specs/app/package.yaml.json
• packages/cli/src/generate/specs/app/package.json

[LoicPoullain]

This is an old issue. Here’s the latest news on that. Some questions have already been answered previously. Others have been resolved in later versions of the framework. And some have remained unanswered.

Here is a follow-up.

Resolved (partially or fully) or answered issues:

• In version 2, the develop command watches and rebuilds scripts when a change is made. So there is no need to rebuild the script each time before running foal run. All you need is to run develop in a separate terminal at the same time.
• In version 2, the number of tsconfig.json has been reduced but there are still three tsconfig and the ormconfig at the root of the directory. Moving these files to another place (a sub-directory) generates many problems (difficulty to resolve the relative paths during compilation, configuration files not found by default by the IDEs, etc), this is why they will be kept in this place in the future.
• New versions of the CLI use npx (thanks for the tip!).

Unresolved issues and follow-up:

• Finally, no new options will be added to the createapp command. The reason behind that is that it adds a lot of work to maintain and it’s very difficult to test. This is one of the reasons, among others, why native support for Mongoose has been dropped.
• Foal won’t include a foal deploy in its commands. This responsibility will be left to the CLIs of the Cloud providers (heroku deploy, etc).
• Having the frontend which auto-reloads when the backends reloads would be a nice improvement. Unfortunately, the compilation in development is currently managed in bash with tsc and supervisor which makes very difficult to add such a feature. Maybe, Foal will have a full CLI one day that handles compilation and reloading, but this won’t happen in the near future.

Based on this comment, I’m going to close this issue.