✨ The Future of Food Truck Management (maybe)
This repository is inspired from the Peck Engineering Assessment
In its current state, TruckDB is a simple-to-use and extensible food truck management API. It is build utilizing Elixir, Ecto and Absinthe with PostreSQL at the database layer. Read on to hear about potential front-end user interface features of this application.
The core target audience for this application are city employees managing the status of their city's food trucks.
As time was a limiting factor in this project, scope had to be limited greatly. There is currently no front-end for this application. One nice feature built into this application currently, however, is the GraphQL schema automatically recompiles when the Elixir code is compiled. This makes it easier for a client-side GraphQL library to incorporate the schema.
Another issue encountered was cleaning up the comma-separated data into a PostgreSQL-friendly format. Initially, this was done with some relatively straightforward regular expressions. As it came closer to actually inserting the data, however, more issues were discovered. Many of these were limited to formatting, thankfully. Having the ability to do this again, a script would have been chosen to import and parse the file and properly create SQL-friendly output.
Initially, there was an attempt to seed the database using Elixir, but a migration with close to 500 rows proved too many.
~/truckdb
├── data.sql
├── docker-compose.yml
└── truckdb
├── README.md
├── config
├── deps
├── lib
├── mix.exs
├── mix.lock
├── schema.graphql
└── test
Let's get you setup to start looking at some food truck data!
git clone git@github.com:danbowles/truckdb.git
cd ~/truckdb
docker-compose up -d
cd truckdb
mix setup
psql -h localhost -U postgres truckdb_dev -f ../data.sql
iex -S mix phx.server
mix test
Once the API is up and running, you can send your browser to:
http://localhost:4000/graphql/graphiql
Included in this tool is the ability to see what queries and mutations may be performed. For convenience, they are listed below.
getTruckById(id: ID!): Truck!
getTruckByLocationId(locationId: String!): Truck!
getTrucks: [Truck!]!
getTrucksByPermitStatus(status: PermitStatus!): [Truck!]!
createTruck(address: String!applicant: String!cnn: String!facilityType: FacilityType!locationId: String!permit: String!schedule: String!status: PermitStatus!): Truck!
deleteTruck(id: ID!): Truck!
updateTruckApplicant(applicant: String!id: ID!): Truck!
updateTruckFacilityType(facilityType: FacilityType!id: ID!): Truck!
updateTruckLatitudeLongitude(id: ID!latitude: String!longitude: String!): Truck!
While this project is on good footing in terms of base functionality, the future is bright when it comes to managing food trucks. Find some future feature ideas below:
- Fuzzy searching with multiple facets
- Paginated results
- Better unique constraints for things like Permits and truck location
- Quality of life endpoints
- Permits expiring in 30 days
- Food trucks with missing data (Location, hours, food items, etc)
- A separate Applicant management system
- Some applicants have multiple trucks
- Applicant contact info
The future here is much more wide-open, but the overall goal is easy-of-use and useful features for truck management.
- A map view with all trucks across the city
- Map pins will lead to management tools or modals and useful links to other municipal tools
- Trucks near me
- A list view with filtering, sorting and searching
- Search by applicant, permit status, city block, etc.
- Shortcuts for useful views
- Trucks with lapsed permits
- Permits per-block/sector
- Trucks missing core information (location, hours, etc)