nimblehq / js-framework-benchmark

Benchmark full-stack JS application frameworks

JS Framework Benchmark

The repository contains POC applications to assess full-stack JS frameworks. The benchmarking process aims to make an informed decision on which framework best suits Nimble.

More information can be found on Notion:

• Engineeing Initiative
• Assessment Criteria
• Scope of the POC applications

Usage

Clone the repository

git clone [email protected]:nimblehq/js-framework-benchmark.git

License

This project is Copyright (c) 2014 and onwards Nimble. It is free software and may be redistributed under the terms specified in the LICENSE file.

About

This project is maintained and funded by Nimble.

We ❤️ open source and do our part in sharing our work with the community! See our other projects or hire our team to help build your product.

Want to join? Check out our Jobs!

js-framework-benchmark's Issues

[Backend] As a user I can logout

Why

Since the application can be used either as an authenticated user or a guest, the application must provide the logout functionality.

Acceptance Criteria

• Implement the logout controller and service layer.
• Ensure no data remains stored on the client device upon logging out.

Set up framework

Why

Before adding features, the framework must be set up with the provided generator. It allows to check the various options available when generating a new project and assess the support for Web and API variants.

Acceptance Criteria

• Create a new directory in the project's root with the framework's name.
• Generate a barebone project using the provided generator.
• Ensure the application can be started simultaneously with the other framework. So a different local port for each application must be used.

[Frontend] As a user I can login with an OAuth provider

Why

Unauthenticated users need to have a UI to login into the application.

Acceptance Criteria

• Implement the UI for the login page.
• Implement the UI for the 403 error page when a user tries to accept a protected route.

[Frontend] As a user I can send a newsletter to a recipient

Why

To link the UI with the background job sending the email, a user must have a form to enter a recipient and select which newsletter to send.

Acceptance Criteria

• Create a new page to email newsletters.
• Add a form to input a recipient email and a button to send the newsletter.
• Add a new button to the list of newsletters routing to the page to email the selected newsletter.

[Frontend] As a user I can logout

Why

To simplify the logging out process, a user must have a UI to log out. Calling a route manually or clearing the local storage would be cumbersome. In addition, it allows checking the support of creating forms with a route using the HTTP verb DELETE.

Acceptance Criteria

• Implement the UI for the logout form/button.
• Ensure the user is redirected to the login page

[Backend] As a user I can logout

Why

Since the application can be used either as an authenticated user or a guest, the application must provide the logout functionality.

Acceptance Criteria

• Implement the logout controller and service layer.
• Ensure no data remains stored on the client device upon logging out.

[Backend] As a user I can login with an OAuth provider

Why

Integrating a third-party service is an oft-required basic need. In addition, implementing an OAuth authentication provider can make building a POC simpler.

Acceptance Criteria

• Set up the third-party library required for Google login. Ideally, Passport should be used instead of NextAuth.
• Create a new table to store users.
• Implement the model, controller, and service layers for the login.
• Implement logic for protected and public routes, i.e., return a 403 error page when accessing a protected route.

Create GitHub Action CI workflow

Why

The test suite must be run on every pull request to get a fast feedback loop.

Acceptance Criteria

• Add new workflow to run tests.
• Execute tests in the GH Action runner. Do NOT use Docker.
• Execute tests on the event pull_request.

[Frontend] As a user I can logout

Why

To simplify the logging out process, a user must have a UI to log out. Calling a route manually or clearing the local storage would be cumbersome. In addition, it allows checking the support of creating forms with a route using the HTTP verb DELETE.

Acceptance Criteria

• Implement the UI for the logout form/button.
• Ensure the user is redirected to the login page

[Backend] As a user I can delete a newsletter

Why

Users can delete records of newsletters as needed.

Acceptance Criteria

• Add a new route to delete newsletters.
• Update the controller and service layers to delete newsletters.

Create GitHub Action CD workflow

Why

The application must be deployed to test out application and error monitoring tools.

Acceptance Criteria

• Add new workflow to deploy the application to fly.io.
• Execute deployments when merging to develop and main.

[#28] Set up frontend application for UI rendering

Why

Since NestJS does not have built-in support for React, the POC is used to research the possible ways to use React with the framework.

Acceptance Criteria

• Implement UI with server-side rendering
• Implement UI with client-side rendering (as a SPA)

[Frontend] As a user I can edit a newsletter

Why

Users can edit records of newsletters as needed.

Acceptance Criteria

• Add a button in the newsletter list to access the page to edit a newsletter.
• Show validation errors in the form to edit a newsletter.

[Backend] As a user I can send a newsletter to a recipient

Why

Sending an email in the background is an oft-required feature, thus implementing it would allow checking the built-in solutions or the need to bring in third-party libraries.

Acceptance Criteria

• Implement the controller, service, and job layers to send an email via Mailgun.
• Ideally, a mail catcher solution should be added to the development environment.

[Backend] As a user I can send a newsletter to a recipient

Why

Sending an email in the background is an oft-required feature, thus implementing it would allow checking the built-in solutions or the need to bring in third-party libraries.

Acceptance Criteria

• Implement the controller, service, and job layers to send an email via Mailgun.
• Ideally, a mail catcher solution should be added to the development environment.

[Backend] As a user I can logout

Why

Since the application can be used either as an authenticated user or a guest, the application must provide the logout functionality.

Acceptance Criteria

• Implement the logout controller and service layer.
• Ensure no data remains stored on the client device upon logging out.

[Frontend] As a user I can list newsletters

Why

Users must have a list from which they can edit or delete the newsletters.

Acceptance Criteria

• Create a basic UI to list all newsletters.
• Do NOT implement any pagination.

[Backend] As a user I can edit a newsletter

Why

Users can edit records of newsletters as needed.

Acceptance Criteria

• Add a new route to edit newsletters.
• Update the controller and service layers to update newsletters.
• Ensure validation rules are implemented.

Set up Remix application

Why

Before adding features, the framework must be set up with the provided generator. It allows to check the various options available when generating a new project and assess the support for Web and API variants.

Acceptance Criteria

• Create a new directory in the project's root with the framework's name.
• Generate a barebone project using the provided generator.
• Ensure the application can be started simultaneously with the other framework. So a different local port for each application must be used.

[Frontend] As a user I can edit a newsletter

Why

Users can edit records of newsletters as needed.

Acceptance Criteria

• Add a button in the newsletter list to access the page to edit a newsletter.
• Show validation errors in the form to edit a newsletter.

[Backend] As a user I can list newsletters

Why

Users must have a list from which they can edit or delete the newsletters.

Acceptance Criteria

• Create a new table to store newsletters.
• Create the controller and model layers for newsletters.

[Backend] As a user I can logout

Why

Since the application can be used either as an authenticated user or a guest, the application must provide the logout functionality.

Acceptance Criteria

• Implement the logout controller and service layer.
• Ensure no data remains stored on the client device upon logging out.

Create GitHub Action CI workflow

Why

The test suite must be run on every pull request to get a fast feedback loop.

Acceptance Criteria

• Add new workflow to run tests.
• Execute tests in the GH Action runner. Do NOT use Docker.
• Execute tests on the event pull_request.

[Backend] As a guest I can view a newsletter content

Why

In addition to the login page, this page is the only unprotected route, thus allowing to have a mix of public and private routes.

Acceptance Criteria

• Add a new route to view a newsletter by id.
• Show a 404 error page when a newsletter cannot be found for a specific id.

[Backend] As a user I can list newsletters

Why

Users must have a list from which they can edit or delete the newsletters.

Acceptance Criteria

• Create a new table to store newsletters.
• Create the controller and model layers for newsletters.

[Frontend] As a user I can send a newsletter to a recipient

Why

To link the UI with the background job sending the email, a user must have a form to enter a recipient and select which newsletter to send.

Acceptance Criteria

• Create a new page to email newsletters.
• Add a form to input a recipient email and a button to send the newsletter.
• Add a new button to the list of newsletters routing to the page to email the selected newsletter.

[Frontend] As a user I can delete a newsletter

Why

Users can delete records of newsletters as needed.

Acceptance Criteria

• Add a button in the newsletter list to delete a newsletter.
• Redirect to the list of newsletters when the deletion is completed.

Set up new NestJS application

Why

Before adding features, the framework must be set up with the provided generator. It allows to check the various options available when generating a new project and assess the support for Web and API variants.

Acceptance Criteria

• Create a new directory in the project's root with the framework's name.
• Generate a barebone project using the provided generator.
• Ensure the application can be started simultaneously with the other framework. So a different local port for each application must be used.

[Frontend] As a user I can create a newsletter

Why

Users can add new records of newsletters as needed.

Acceptance Criteria

• Create a page with the form to create a newsletter.
• Add a button on the newsletter index page to access the page to create a newsletter.
• Show validation errors in the form to create a newsletter.

[Backend] As a user I can delete a newsletter

Why

Users can delete records of newsletters as needed.

Acceptance Criteria

• Add a new route to delete newsletters.
• Update the controller and service layers to delete newsletters.

[Frontend] As a user I can logout

Why

To simplify the logging out process, a user must have a UI to log out. Calling a route manually or clearing the local storage would be cumbersome. In addition, it allows checking the support of creating forms with a route using the HTTP verb DELETE.

Acceptance Criteria

• Implement the UI for the logout form/button.
• Ensure the user is redirected to the login page

[Frontend] As a user I can list newsletters

Why

Users must have a list from which they can edit or delete the newsletters.

Acceptance Criteria

• Create a basic UI to list all newsletters.
• Do NOT implement any pagination.

[Frontend] As a guest I can view a newsletter content

Why

A link to a public route is an oft-required feature, hence the need for a public route with an ID.

Acceptance Criteria

• Implement the UI to render a single newsletter content.
• Add a small banner to inform users that they can login.

[Backend] As a user I can login with an OAuth provider

Why

Integrating a third-party service is an oft-required basic need. In addition, implementing an OAuth authentication provider can make building a POC simpler.

Acceptance Criteria

• Set up the third-party library required for Google login. Ideally, Passport should be used.
• Create a new table to store users.
• Implement the model, controller, and service layers for the login.
• Implement logic for protected and public routes, i.e., return a 403 error page when accessing a protected route.

[Frontend] As a user I can login with an OAuth provider

Why

Unauthenticated users need to have a UI to login into the application.

Acceptance Criteria

• Implement the UI for the login page.
• Implement the UI for the 403 error page when a user tries to accept a protected route.

[Frontend] As a user I can create a newsletter

Why

Users can add new records of newsletters as needed.

Acceptance Criteria

• Create a page with the form to create a newsletter.
• Add a button on the newsletter index page to access the page to create a newsletter.
• Show validation errors in the form to create a newsletter.

[Backend] As a guest I can view a newsletter content

Why

In addition to the login page, this page is the only unprotected route, thus allowing to have a mix of public and private routes.

Acceptance Criteria

• Add a new route to view a newsletter by id.
• Show a 404 error page when a newsletter cannot be found for a specific id.

[Backend] As a user I can list newsletters

Why

Users must have a list from which they can edit or delete the newsletters.

Acceptance Criteria

• Create a new table to store newsletters.
• Create the controller and model layers for newsletters.

Create GitHub Action CI workflow

Why

The test suite must be run on every pull request to get a fast feedback loop.

Acceptance Criteria

• Add new workflow to run tests.
• Execute tests in the GH Action runner. Do NOT use Docker.
• Execute tests on the event pull_request.

[Frontend] As a guest I can view a newsletter content

Why

A link to a public route is an oft-required feature, hence the need for a public route with an ID.

Acceptance Criteria

• Implement the UI to render a single newsletter content.
• Add a small banner to inform users that they can login.

[Frontend] As a user I can logout

Why

To simplify the logging out process, a user must have a UI to log out. Calling a route manually or clearing the local storage would be cumbersome. In addition, it allows checking the support of creating forms with a route using the HTTP verb DELETE.

Acceptance Criteria

• Implement the UI for the logout form/button.
• Ensure the user is redirected to the login page

[Backend] As a user I can delete a newsletter

Why

Users can delete records of newsletters as needed.

Acceptance Criteria

• Add a button in the newsletter list to delete a newsletter.
• Redirect to the list of newsletters when the deletion is completed.

[Frontend] As a user I can list newsletters

Why

Users must have a list from which they can edit or delete the newsletters.

Acceptance Criteria

• Create a basic UI to list all newsletters.
• Do NOT implement any pagination.

[Frontend] As a user I can login with an OAuth provider

Why

Unauthenticated users need to have a UI to login into the application.

Acceptance Criteria

• Implement the UI for the login page.
• Implement logic for protected and public routes, i.e., return to the login page with an error when accessing a protected route.

[Backend] As a user I can create a newsletter

Why

Users can add new records of newsletters as needed.

Acceptance Criteria

• Add a new route to create newsletters.
• Create the controller and service layers to create newsletters.
• Ensure validation rules are implemented.

[Backend] As a user I can login with an OAuth provider

Why

Integrating a third-party service is an oft-required basic need. In addition, implementing an OAuth provider for authentication can make it simpler to build a POC.

Acceptance Criteria

• Set up the third-party library required for Google login.
• Create a new table to store users.
• Implement the model, controller, and service layers for the login.

[Backend] As a user I can edit a newsletter

Why

Users can edit records of newsletters as needed.

Acceptance Criteria

• Add a new route to edit newsletters.
• Update the controller and service layers to update newsletters.
• Ensure validation rules are implemented.

Set up new Next.JS 13 application

Why

Before adding features, the framework must be set up with the provided generator. It allows to check the various options available when generating a new project and assess the support for Web and API variants.

Acceptance Criteria

• Create a new directory in the project's root with the framework's name.
• Generate a barebone project using the provided generator.
• Ensure the application can be started simultaneously with the other framework. So a different local port for each application must be used.

[Backend] As a user I can create a newsletter

Why

Users can add new records of newsletters as needed.

Acceptance Criteria

• Add a new route to create newsletters.
• Create the controller and service layers to create newsletters.
• Ensure validation rules are implemented.

[Backend] As a user I can login with an OAuth provider

Why

Integrating a third-party service is an oft-required basic need. In addition, implementing an OAuth provider for authentication can make it simpler to build a POC.

Acceptance Criteria

• Set up the third-party library required for Google login.
• Create a new table to store users.
• Implement the model, controller, and service layers for the login.
• Implement logic for protected and public routes, i.e., return a 403 error page when accessing a protected route.