x-lab-lbq

Overview

This is a very simple implementation of a standard datafetching backend-frontend piece. It may seem very simple and not very feature rich (and look quick ugly!), however I feel like it's a good representation of the approaches I would take to a brand new full stack application, without implementing all of the future features.

It shows the CSV data given as a simple grid, where the user can filter based on tags and categories.

Technology Used

Backend

• .NET Core 6 - ASP.NET API
• Entity Framework

Frontend

• Vanilla React w/ Vite
• React Query - React Router
• Testing with Jest and React Testing Framework

Development Tools

This project was primarily developed on Kubuntu 22.04, but has been tested on Windows 10.

• .NET 6
• NodeJS v16.17.0
• Rider 2022.2.3 (.NET)
• DataGrip 2022.2.5 (Database)
• WebStorm 2022.2.3 (React/FE)
• VSCode 1.72.2 (React/FE/Docs)
• Insomnia
• Misc KDE tools

Setup

Brief instructions on how to get the solution running locally. There was not enough time to get deployment scripts written, so only dev-mode is supported at the moment.

Prerequisites:

• .NET 6 SDK
• NodeJS (I used v16.17.0, so any >=v16 should work) w/ NPM

Backend

Migrations

First, make sure the database is created and migrations are run correctly. The backend uses standard EF migrations that can be completed by running the following commands:

First, assure the entity framework tool is installed (and that you have the .NET!):

dotnet tool install --global dotnet-ef

The following should be run in the ./backend/LeedsBeerQuest.API/LeedsBeerQuest.API/ directory -

Then run the migrations, this will also create a local SQLite database that the app will use (in the default directory):

dotnet ef database update

Data Seeding

Data seeding is something I've done in projects before (usually through EF migrations), however it seemed to have issues with test data and testing scenario constants (particularly using an in-memory database). Feel free to checkout the seed data migration commit here to see what the seeded migration looks like.

The database should seed automatically when launched for the first time, if compiled with the LBQ_SEED_DATA constant. It will read the leedsbeerquest.csv from the LeedsBeerQuest.API directory. It will only seed the database with the CSV data if there is no existing data in the database. The CSV location can be configured in appsettings.json at Database:Seed:SeedDataLocation.

Running

To run the application, navigate to the ./backend/LeedsBeerQuest.API/LeedsBeerQuest.API/ directory and run:

dotnet run

This will run the application at https://localhost:7021/ (assuming the default config is used).

Running tests

Only standard unit tests are included.

To run the tests, navigate to the ./backend/LeedsBeerQuest.API/LeedsBeerQuest.API/ directory and run:

dotnet test

Frontend

Running

To run the development version, navigate to the ./frontend/leeds-beer-quest/ directory and run:

npm run dev

Building

To build the production version, navigate to the ./frontend/leeds-beer-quest/ directory and run:

npm run build

This will produce a build that can be deployed (sorry for no instructions on deployment!).

Running Tests

To run all of the test suites, navigate to the ./frontend/leeds-beer-quest/ directory and run:

npm run test

Environment Settings

The ./frontend/leeds-beer-quest/src/lib/environment.ts file should already contain the correct location for the backend API, however if it does not, you should modify the BaseAPIUrl property to be the same path as your backend instance.

How can I improve?

A Better Seeder

The seeding mechanism isn't great. I would probably like to have kept them as migrations if I hadn't run into issues during development.

Microservices

There are three clear entities that could be split out into microservices (they might be a little too similar to split them out, however it should be considered), Venues, Tags and Categories. I personally wouldn't split them out, but I can see the benefits of maintainability.

More and better tests

Only unit tests are included, which are good however integration and automated tests would be ideal for production software.

Pagination

Pagination is something that I've not really had a chance to look into (apart from a bit of it in Laravel), so it would have been nice to deal with it here to learn a bit more about it. And make the index page perform much nicer with the searches.

DTOs

Returning raw database objects as responses isn't really ideal (and I found an issue with many-to-many relationships which causes an infinite loop in the JSON parser!), so it would be ideal to use DTOs when returning objects from the API.

More and better configuration

Right now, there's little in the way of user configuration. Ideally, most 'environment' variables would be configurable either through the appsettings.json file or through environment variables.

A better UI

The UI isn't great, and doesn't really do its purpose of displaying data in a good way for a user.

Better error handling

More for the frontend, but backend doesn't have the best either. More checks make the user experience much better.