# 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!): ```bash 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): ```bash 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](https://github.com/Stedoss/x-lab-lbq/commit/add80a3521495445f9e5abb9cfe399c80d28e6c7) 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: ```bash 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: ```bash dotnet test ``` ### Frontend #### Running To run the development version, navigate to the `./frontend/leeds-beer-quest/` directory and run: ```bash npm run dev ``` #### Building To build the production version, navigate to the `./frontend/leeds-beer-quest/` directory and run: ```bash 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. ### 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. ## 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.