Skip to content

Using Remix SSR as an opportunity to explore hexagonal architecture for Web Apps

License

Notifications You must be signed in to change notification settings

antoinechalifour/remix-hexagonal-architecture

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Todo List Manager

This project showcases an hexagonal architecture approach for front-end projects.

Cover

This is a Remix and Nest application, you may want to check out the Remix documentation and the Nest documentation.

Context

Modern tooling blurs the front-end line. Front-end does not mean Client-side anymore. Frameworks like Next.js or Remix.run enable libraries like React to run in a browser-less environment at request-time (and at build-time if you're using Next.js's getStaticProps).

This enables new architectural patterns for front-end developers, which can now move some logic to the server. This can improve security and make some things easier, for instance :

  • authentication using cookies ;
  • secrets can be safely stored and used on the server ;
  • data fetching can be made directly from the database (the API layer is often abstracted. See Next.js, Remix.run) ;

Seeing the blurred line between client-side and server-side, there is now an opportunity to use an "unified hexagon", leaving generic concerns (like data fetching) to your framework of choice.

Principles

This project is based on the following principles :

  • most of the work should be done on the server ;
  • specifically, any data preparation should happen on the server ;
  • the client responsibility is primarily using traditional Web features like forms and navigation ;

Implementation

The project is organized as such :

  • app/* : where React components and Remix stuff lives ;
  • src/<module>/(domain|usecase) : where domain modeling happens for writing operations (domain interfaces, behaviors and ports) ;
  • src/<module>/persistence : where repositories are implemented (for persisting aggregates) ;
  • src/<module>/query : where queries are modeled for reading operation (preparing data for our pages) ;
  • src/<module>/application : where the application layer lives (glue between layers) ;

Limitations

The following limitations have been identified :

  • Since the data structure are sent over the network (client <> server communications), they must be simple objects used as JSON. For instance, complex objects like Date cannot be used as a response for reads or writes.

Useful scripts

Development

From your terminal:

docker-compose up # Launches databases
yarn dev # Boot app

This starts your app in development mode, rebuilding assets on file changes.

Tests

From your terminal:

yarn test

This runs the automated tests against the source code.

E2E tests

The project uses Cypress to automatically interact with the app, like a user would do.

From your terminal:

yarn e2e:run

This runs the E2E tests in your terminal. If you want to "see" the tests running in the browser, use:

yarn e2e:dev

You can also launch Cypress and the test environment separately to debug / write tests :

yarn e2e:app # Boot the app using E2E configuration (separate database, ...)
yarn cypress:dev 

Deployment

First, build your app for production:

yarn build

Then run the app in production mode:

yarn start

Now you'll need to pick a host to deploy it to.

About

Using Remix SSR as an opportunity to explore hexagonal architecture for Web Apps

Topics

Resources

License

Stars

Watchers

Forks