5.1 KiB
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
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.
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!).
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.
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.
What NEEDS to change
Add unit tests for FE
Even if it's just a few, it will show off how I unit test for the frontend.
A little better configuration for seeding ect
Just to say I have.
Make tags work
The last big thing.