I attend the University of Pittsburgh, and am currently pursuing a Bachelor’s degree in Computer Science. My expected graduation date is May 2027. I am looking for Software Engineering roles. I have past software engineering experience as an intern at Google.
This inventory manager is a full-featured application designed to help users manage their inventory efficiently. It includes user authentication, and reporting dashboards. It was initially built for my IB Computer Science Internal Assessment project, where I gathered client requirements and wrote many design documents. I had pretty much self taught all the technologies used in this project, and it was a great learning experience!
User Authentication: For this project I implemented my own custom user/email authentication system, using salting and hashing.Dashboard: Interactive dashboard displaying real-time stock levels, low-stock alerts, and reorder suggestions.CRUD Operations: Create, read, update, and delete inventory items with ease.Regex Validation: Validates fields like email and phone numbers using regular expressions.I used database migrations in order to keep track of changes to the database schema.
The frontend was built using Tauri, which allows you to create desktop applications using web technologies. The main benefit of using web technologies is that it is very portable and can run on multiple platforms, including Windows, macOS, and Linux (since browsers are mainly universal). This way, my development environment would not be significantly different from the production environment.
Tauri also allows you to call Rust functions from JavaScript without calling the backend, which is very useful for performance-intensive tasks like database queries and data processing.
Not only this, but Rust enforces strong type safety compared to Typescript, which keeps the application secure and predictable. The Rust data types are automatically synced with typescript using Tauri. Therefore, the model classes are the same in both the frontend and backend, which reduces the chances of bugs and makes the code more maintainable.
Asyncronous programming is used extensively in this project to ensure that the application remains responsive while performing database operations or network requests.
Database pooling is implemented to manage database connections efficiently, allowing multiple requests to be handled concurrently using the same database connection. This improves performance and reduces the overhead of establishing new connections for each request.
models.rs contains the data models for the all items stored in the database, such as Product, User, and PendingOrder. Each model is built using a Builder pattern, which allows for easy and consistent construction of complex objects. Not only this, but all the operations are consistent, since the models have their own methods for the common operations.
Authorization is handled using an AuthGuard, which is middleware that checks if the user is authenticated before allowing access to certain routes. It does this by checking the password hash in the request headers and verifying it against the database. If the username/password combination is valid, the user is allowed to access the route.
First Takeaway: Although I learned a lot trying to implement my own secure authentication system, in the future it would be more practical to use an existing solution like Firebase or Auth0. This would save time and effort, and make the authentication more maintainable.
For example, because I didn't implement both refresh tokens and access tokens, it does pose a slight security risk, since the client has to continuously send their password in the request headers to access protected routes. This is debatably less secure than only logging in once, and using a temporary token to continuously authorize the client.
The second issue is that it is much slower, since hashing and salting passwords is meant to be a slow operation. Having a refresh token would allow the client to get a new temporary access token without having to send their password again, which would improve performance and security.
Second Takeaway: Tauri was a very smooth development experience, and I would recommend it to anyone looking to build a desktop application using Rust. When I initially started this project, I was looking at Slint because it was fully native. However, I quickly switched to Tauri because at the time, Slint did not have a stable release and was still in beta. Because Tauri uses web technologies, you can easily borrow a lot of th stability of tried and tested UI technlogies such as HTML, CSS, and JavaScript.
Third Takeaway: An improvement to increase reliability would be to use GraphQL or gRPC instead of REST for the API. This would allow for more efficient data fetching and reduce the number of requests needed to get the data. It would also allow for more flexibility in the data structure, since GraphQL allows you to specify exactly what data you want in the response. The data models would also be more consistent, since the same schema would be used for both the frontend and backend. This works well with Tauri, since it allows you to call Rust functions from JavaScript without calling the backend. Since REST uses JSON, it does not provide much benefit over GraphQL or gRPC, since the frontend no longer has to make HTTP requests using Javascript/TypeScript, but can call Rust functions directly.
Languages: Rust, TypeScript
Frameworks: Tauri, Rocket.rs, Diesel ORM and migrations, Svelte Frontend Framework
Technologies: REST API, NGrok for deployment
Database: PostgreSQL