More Suggestions

[Sharlaan]

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]

Hi Sharlaan,

Thanks for your suggestions! Glad that you like the framework.

@foal/cli is awesome !

Thanks!

• foal createapp : would it be possible to make it like vue-cli which asks a serie of questions.

This could be done. We can discuss on the questions and the files and directory structure that should be generated. The big challenge here will be to test all of that. We need to be able to test:

• the CLI prompts
• the generated projects (compilation, behavior of the API, etc).

Maybe we should also reduce the number of questions to a small number. I don't know how many questions the vue CLI asks. Around five I guess? The SRR vs SPA point sounds really useful. Maybe include/ignore OpenAPI docs is less vital? Could an authentication prompt with Generate Login and SignUp controller? be interesting as well?

About when/if the questions should appear, an --advanced flag could be added to the foal createapp command. foal createapp my-app would simply generate a basic project. foal createapp --advanced would ask series of questions to create a more complex app.

• 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)

I'm not sure to understand your point here. foal g graphql-api could be added as well, isn't it?

• 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 ?

Yeah, it's true that it's annoying. I have the same problem. The reason why the build is separated from the execution is that, when deploying an application to production, we only deploy the JS files. However, maybe we could end up with a solution like this:

foal run my-script

1. If src/scripts/my-script.ts exists, then build it. If not, then go to 2. (it means that we are in the deployment server, the source code is not available)
2. Run the script with build/scripts/my-script.js

foal run my-script --no-build

Current behavior of foal run:

1. Run the script with build/scripts/my-script.js

foal deploy based on createapp answers would be helpful

Do you have something in mind?

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

Yes, it was purposely to keep the tutorial short. Do you think it's annoying? Did you have trouble implementing this route?

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

Yes, this would be a nice feature and it should be implemented at some point. Could you open a separate issue for this? The ideal choice would be to be able to do this with both a Regular Web App (using SSR) and a SPA+API app (talking for example to Vue CLI to tell it to refresh the browser).

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

I'd rather not add too much external dependencies to Foal. Is there a particular reason to choose npx by default over the current implementation?

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 ?

Several points here:

• Moving ormconfig.js|json|yml to the config/ directory is complicated because the createConnection TypeORM function expects the file to be located at the root directory as default behavior.
• Same with tslint.json and tsconfig.json: most editors and IDE expect these files to be at the root of the project for their internal tools (syntax highlighting, linting auto-fix, etc).
• tsconfig.xxx.json could be moved to config/. Some checks should be done on this because tsconfig files handle inheritance and relative paths really weirdly.
• Starting from version 1, the config/ directory will contain more files by default (e2e.json, test.json, etc). It will also contain default TypeORM configuration for each environment (for example, database schema will be dropped before running unit tests). I'll write a detailed guide about how to upgrade and what changes.

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

Thanks, I really appreciate. It takes me time to write these tutorials. Some others will come up this summer based on what you suggested: OpenAPI, Password Reset, GraphQL, Social Auth etc 🚀

[Sharlaan]

This could be done. We can discuss on the questions and the files and directory structure that should be generated. The big challenge here will be to test all of that. We need to be able to test:

You are right, setting priorities should help. In my humble opinion, most important ones to get a fully functional running project would be :

• architecture : SSR or SPA, REST or GraphQL, by type or by functionality, which DB, and which frontend framework
• authentication/authorization: strategies(login/pw[, social]), roles

Regarding auth prompts, i wish they would generate the full code, allowing the developer to start asap adding functionalities with a fully running authentication/authorization system. The other features sound indeed more "peripheral", like Docker, OpenAPI, CI/CD or Logging.

Cool idea with --advanced 👍

I'm not sure to understand your point here. foal g graphql-api could be added as well, isn't it ?

i was thinking about reusing same function used for foal createapp question REST or GraphQL using foal g add-api -- 'graphql' with 'rest' or 'graphql' as params.
But yeah using 2 distinct commands could work as well, given resulting architectures are very different :)

• foal run my-script : how about using NODE_ENV ?

foal deploy based on createapp answers would be helpful Do you have something in mind?

CI/CD, Netlify, Docker ?

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

Yes, it was purposely to keep the tutorial short. Do you think it's annoying? Did you have trouble implementing this route?

Not annoying, just surprising. I wrote it in api.controller.ts :

  @Patch('/todos/:id')
  // @ApiParameter()
  // @ApiRequestBody()
  @ApiResponse(200, { description: 'Successfully updated' })
  @ApiResponse(400, { description: 'Invalid request parameters supplied' })
  @ValidateParams({
    properties: {
      // The id should be a number. If it is not (the request.params object
      // always has string properties) the hook tries to convert it to a number
      // before returning a "400 - Bad Request".
      id: { type: 'number' },
    },
    type: 'object',
  })
  @ValidateBody({
    additionalProperties: false,
    properties: {
      text: { type: 'string' },
    },
    type: 'object',
  })
  async updateTodo(ctx: Context) {
    const searchCriteria = {
      id: ctx.request.params.id,
      owner: ctx.user, // Do not search for a todo not owned by the current user.
    };
    const updatedContent = {
      text: ctx.request.body.text,
    };
    // Update the todo with the id given in the URL.
    const updatedTodo = await getRepository(Todo).update(searchCriteria, updatedContent);

    // Returns a successful empty response. The status is 200.
    return new HttpResponseOK(updatedTodo);
  }

is it correct ?

npx is not an additional dep, as it is already included in the required NodeJS (within npm) for FoalTS :p I suggested this just for readability.

[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

[chuongtrh]

Hi @LoicPoullain With the part docker, Could you give a sample Dockerfile in the meantime waiting foal-cli support generate Dockerfile? Thanks!

[LoicPoullain]

@chuongtrh I don't have a particular one on hand. Could the the node image simply be used in that case?

[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.