damien-carcel / app-skeleton Goto Github PK

The front-end application currently uses 7.0rc1 since PR #127.

Each time the front-end application is rebuilt using webpack, the nginx-front container needs to be restarted, or the application doesn't work anymore.

This is counterproductive and must be solved. There are 3 possibilities for that:

• Find out what is causing the issue on the Nginx side and fix it => seems there is no way to fix it but restart the server
• Test Apache instead of Nginx => same issue, only show an empty index instead of a 403 error
• Don't use Nginx anymore on the front-end (solve the problem of hot reloading too)
  • Only the back-end will still be on Docker
  • Use directly the Webpack dev server for the front-end
  • Use two separate Docker Compose files, one for the back, the other for the front, but keep an Nginx server in the front one for testing purposes

What tools to use for front-end?

• static analysis (tslint is already in place, it there more to do?)
• unit test
• integration tests
• acceptance tests (are there useful? Is there really business in the front-end?)
• system tests (should they be done in behat only, so we can access the database easily? Selenium or pure Chrome driver?)

Is this pattern (coming from full stack app) relevant for full front app?
Should there be rendering tests too, like with a comparison with a reference screenshot?

• Rewrite everything from Scratch
• Test with Jest for unit and integration tests, Cypress for end-to-end tests, add JUnit output on the CI when possible
• Use styled components

• Introduce an XML configuration file, base on the PSR-2
• Run on all the code, phpspec included, but remove the rules that are in conflict with phpspec codestyle (method visibility, signatures, and name in camelCase)

Update both the CI and the composer scripts.

• Complete requirements for both front-end and back-end applications
• Create a folder doc at the root of the application that will contain the documentation
• Create installation documentations for front-end and back-end applications, both local and Docker
  • remove the READMEs of the front-end and back-end applications => make it the local install documentations
• Create "configure" documentations explaining how to run the two apps together with:
  • full local setup
  • full Docker setup
  • the main README must be as short as possible, containing only links to the various documentations inside the doc folder

As the application is a bootstrap for real projects, it should be tested properly.

• Remote the *.yml.dist files, use only yaml + environment variables
• Add usage of docker-compose.override.yaml for docker-compose customization (all branches)
• Add one real test of each sort
• Add Travis CI

These changes will be merged to the symfony-api branch too.

• #79 - Solve the CORS issue when running fully on Docker
• #144 - Replace the "Post" entity with a "User" entity
• #145 - Switch the application to a command/query pattern
• #146 - Add akeneo/php-couplig-detector
• #194 - Use value objects in models
• #147 - Handle commands and queries with Symfony Messenger component
• #231 - Remove Doctrine ORM
• #233 - Use Symfony Validator component
• #148 - Install and configure API Platform

Update all back-end dependencies in the process.

webmozart/assert is to be moved in production requirements, as it will be used in value objects in the near future.

Right now, a configuration file config/api.json is used to configure the front-end application.

• The routes should be hard-coded in the containers, and the back-end application updated so the routes are the same than with the json-server used for development.
• The rest of the configuration should be one environment variable, setup in the system or in the containers:

  "protocol": "http",
  "host": "nginx-back",
  "port": 80,

php-cs-fixer is enough, and all its rules have a fixer, which is far from being the case with PHP Code Sniffer.

• Update to webpack 4
  • Update impacted branches: master, react, and `symfony
  • Keep only one config file thanks to the new modes (remove plugin webpack-merge)
  • Remove deprecated plugin extract-text-webpack-plugin (which means no more chunks nor extracted CSS)
• Replace favicons-webpack-plugin by webapp-webpack-plugin
• Find a new way to extract CSS in production with hashed names
• Add static analysis to Travis CI

Inherit from react-symfony, removes all front elements.

[Reopened] - Keep CSS and JavaScript. Replace HTML with TWIG.

Manage states with redux. To see if still relevant once React Hooks are stable.

Make use of Composer scripts capabilities, like with Yarn for the front-end.
Update the README accordingly.

Will ease the merges with react-symfony branche.

TS 3.0 was released a couple of weeks ago. The front-end application currently use TS 2.9.

It should be upgrade if all dependencies (like React) are compatible with this new major release.

Instructions: https://www.npmjs.com/package/image-webpack-loader
Use only in production.

Check everything and make it more consistent with my coding style.

For example: comma-dangle should use always-multiline.

Try to only use needed services through DI.

Since #124, End to End tests are using Chrome and the chromedriver, directly controlled from Behat Mink thanks to dmore/behat-chrome-extension.
For a simple configuration and usage, Chrome is currently installed directly in the fpm image.

However, this is not a good solution, and it should have its own dedicated image. The chosen solution is to use Selenium with Chrome in headless mode. Even if it is slower (benchmark and configuration are provided in the comment below), it is way easier to use, both locally and with Docker (no more Chrome to launch, Selenium do it for us).

As the back-end application is a full REST API, it doesn't need a real web browser. The BrowserKitDriver used by default by the Mink extension (that was used previously) is enough. Test inside a real web browser will be performed on the front-end application, with CucumberJS and Chrome headless.

• Remove dmore/behat-chrome-extension, install and configure behat/mink-selenium2-driver
• Update the documentation
• Update Travis configuration

• Should it replace phpspec?
• Should prophecy still be used for mocking?
• Should phpunit-bridge be used?
• Should phpspec be kept, just adding a code coverage?

Relates to epic #143.

For now, the front-end and back-end applications are to be used with the same domain name.

Update the documentation to explain localhost is always to be used, even when fully under Docker (using an external network, there is no need to call the back-end app using fpm namespace).

It is currently on 9000, which can conflict with XDebug on the back-end app.

This change is to be done on docker-compose too.

Keep only master:

• add a front part with the content of current react branch,
• add a back part with the content of current symfony-api,
• replace the milestones with labels,
• create a global docker-compose.yaml file at the root of the project

symfony branch is useless, as it can be achieved very quicly, if necessary, with symfony/website-skeleton, adding to it the backend test stack from this repository.

In the same way, master branch can be quickly re-created by cleaning the front stack of the react branch.

Symfony requires it and it will just be a nightmare to merge branches otherwise.

• Remove the react-symfony branch and its milestone
• Use fetch API to get a list of posts
  • manage the Ajax calls https://reactjs.org/docs/faq-ajax.html
• Add react-modal and implement forms
  • use react-modal for blog post create
  • use react-modal for blog post update (use get to retrieve the blog post)
  • implement blog post delete
• Test the application with both the API skeleton and the JSON server
  • fake the routes
  • make the app configurable to switch between the JSON server and the real Symfony API
  • document both way of running the app (README)

As the client application is to be a PWA, service workers would certainly be handy.
Let see what they can bring.

There are several maintained branches, one inheriting from another.

Describe each of them, their purpose, and which one inherit from which one.

Accept only one method (GET, POST...) for each route.

• Add the branch in the README
• Remove all front elements
• Implement a basic REST API for CRUD

• Rename system tests to end-to-end
  • change profile name and tags
  • use EndToEnd namespace
• Install and configure Chrome Mink driver with its Behat extension
  • make it run locally
  • make it run with Docker
  • make it run on Travis
• Document how to launch system tests in headless mode and in regular mode, locally and with Docker

The goal is to have a specific test environment for acceptance tests, where third party services can be replaced. For example, repositories using Doctrine in the real app (and in system and integration tests) could be in memory in this environment.

• This is configured in behat at the profile level (there is currently only the default one) => one profile per sort of test
• System tests and acceptance tests use the same behat scenarios, only system tests are tagged @system and use different contexts
• If possible, service definition should be avoid and autowiring used whenever possible, including for the multiple service definition => ideally, only an override/alias should be created in the acceptance environment to replace Doctrine by an "in memory" system

• Checks the rules: Symfony:risky are quite useless, and some of the specific ones used are already present in @Symfony
• Add @PHP71Migration and @PHP71Migration:risky
• Run it on the spec too, but with a different configuration, so the methods can have no visibility and no signature

Update both the CI and the composer scripts.

Currently, only JavaScript is linted, but CSS/Less needs to be too.

• Add stylelint package
• Configure it

Investigate webpack-manifest-plugin and inline-chunk-manifest-html-webpack-plugin.

Implement a real User management following this documentation

• A new User model that implements the Symfony UserInterface should be created, in infrastructure only.
  • Only this model should be used in the authentication mechanism.
  • A custom provider will allow using this new User model, filling it with GetUser::byUsername query.
• Store the user password
• Encode the user password
• As the provider works through the username (the email in our case) and not the user ID, we need to add a validation to ensure the user email is always unique
  • both at the application level and at the database level
  • index the email in MySQL as we use it to query the user sometimes
• Use the newly implemented authentication and test the authentication mechanism at the API level
• Add a login screen This will be done in #142

Create a new branch that will inherit from the react branch, adding Symfony 4 as a backend.

http://www.phpspec.net/en/stable/cookbook/templates.html

• Investigate Symfony authentication
  • Use Guard (https://symfony.com/doc/current/security/guard_authentication.html)
  • Add an in memory user?
• Implement an API key authentication
• Administration should be provided only through console commands (no authentication needed, only direct access to the server)

Should the behat Symfony extension currently used in symfony and symfony-api branches be replaced by the FOB extensions? => YES!
Could it solve the problem of DI (acceptance and test environments services being all public for instance)? => It does
Is there a easy workaround to use correct environment for the different kinds of test (the old Symfony extension allows to specify which environment to use for a particular behat profile, not FOB)? => Use APP_ENV before launching the command

Use the same example, in hard-coded JSON, in master and react branches.

• Add useful packages listed in https://gist.github.com/damien-carcel/f85f57af289990ddb6190b478d01c020
• Create a simple entity (a blog post for example) and implement a "List" controller
• Add DoctrineFixtureBundle to have some test data

Add a new react branch based on the master branch.

This branch will contain dedicated configuration for ReactJS:

• react and react-dom dependencies
• take in charge React on babel and eslint level
• take in charge JSX on Webpack level

• Add the new needed dependencies
  • Add and configure TypeScript with Webpack
  • Is babel-preset-env still needed? Yes
  • Add typescript support for React
  • migrate JSX to TSX
  • Remove prop-types
• Replace eslint with TSLint
• Investigate prettier and add it if it brings value regarding TSLint => TSLint is enough.